easyeda-extension-packaging

name	easyeda-extension-packaging
description	Use when packaging, auditing, or preparing a 嘉立创EDA / EasyEDA extension for submission, including extension.json completeness, icon requirements, entry validation, README and CHANGELOG checks, privacy review, and pre-release packaging readiness.

EasyEDA Extension Packaging

Package and review a 嘉立创EDA / EasyEDA extension so it is ready for upload, store submission, or compliance checks.

When to Use

Use this skill when the user wants to:

• Audit whether an extension can be uploaded or submitted
• Check whether extension.json is complete and valid
• Verify icon, entry file, README, and CHANGELOG requirements
• Review packaging readiness before release
• Turn store review rules into an actionable checklist

Do not use this skill for API lookup or runtime debugging.

• Use easyeda-api for API classes and methods
• Use easyeda-extension-manifest for deeper manifest structure and headerMenus wiring
• Use easyeda-extension-debugging for runtime issues after installation

Required Packaging Checklist

Treat the following as the baseline review checklist.

1. Manifest Required Fields

extension.json should contain at least:

• name
• uuid
• displayName
• description
• version
• license

Recommended validation rules:

Field	What to check
name	Stable machine-readable extension name; avoid spaces; keep it unique for the extension identity
uuid	32 lowercase letters and digits only for current EasyEDA extension packaging conventions
displayName	Human-readable store name
description	Clear one-line summary of the extension purpose
version	Semantic version such as 1.0.0
license	SPDX-style identifier when possible, such as Apache-2.0 or MIT

If any of these fields are missing, the extension is not packaging-ready.

2. Categories

categories must include at least one supported extension category.

Safe documented values to use in reviews:

• Schematic
• Symbol
• PCB
• Footprint
• Panel
• Library
• Project
• Other

If the extension spans multiple feature areas, multiple categories may be acceptable if the platform accepts them. If not verified, prefer one precise category instead of guessing.

3. Icon Rules

The extension must provide a custom icon.

Review rules:

• Do not use the SDK default logo
• Prefer PNG or JPEG
• Prefer a 1:1 aspect ratio
• Minimum resolution: 200x200
• Maximum file size: 5MB
• The image content must be visually recognizable
• The icon must not create copyright or trademark risk

Practical review standard:

• If the file is square, above 200x200, under 5MB, and clearly not the SDK sample logo, mark it as structurally compliant
• Copyright ownership usually cannot be fully proven from the repository alone; report it as a manual legal confirmation item if uncertain

4. Entry File

entry in extension.json must resolve to a real, valid extension entry bundle.

Check all of the following:

• The referenced file exists in the packaged output or intended upload directory
• The bundle matches the actual build output name
• The entry bundle exports every registerFn referenced by headerMenus
• The path does not point to source-only files unless the runtime explicitly supports that workflow

Common mistake:

If the repository is a source repository and dist/ is gitignored, say:

• The manifest path may still be correct for packaged output
• The current workspace is not directly upload-ready until build artifacts are produced

5. Name Uniqueness Across UUIDs

Different extensions with different uuid values must not share the same name.

Review guidance:

• Inside one repository, verify there is no second extension manifest with a different uuid reusing the same name
• Across multiple published extensions, this usually requires store-side or organization-side verification
• If repository scope is limited, state that cross-repository uniqueness cannot be fully proven locally

6. README Requirements

README.md should explain both functionality and usage.

Minimum acceptable structure:

• What the extension does
• Which editor/page it supports
• How to install or build it
• How to use it inside EasyEDA
• Any known limitations or compatibility notes

A README that only describes development commands is not enough for submission readiness.

7. CHANGELOG Requirements

CHANGELOG.md should describe release history.

Minimum acceptable content:

• Current version entry
• Summary of added, changed, or fixed items
• Older versions retained when available

If a changelog exists but does not mention the current released version, flag it as incomplete.

8. Privacy Review

The extension package must not include private personal information such as phone numbers.

Review at minimum:

• extension.json
• README.md
• CHANGELOG.md
• source files under src/, iframe/, locales/, config/

Sensitive data to flag:

• Personal phone numbers
• Personal email addresses when not intentionally public project contacts
• ID numbers, addresses, access tokens, credentials, or secrets

Be careful not to false-positive on:

• UUIDs
• version numbers
• CSS @media
• image filenames containing dates

Recommended Audit Flow

When asked to analyze a project, review in this order:

1. Read extension.json
2. Verify entry, images.logo, categories, and required fields
3. Check the real icon file dimensions and size
4. Check whether the entry file exists in the expected output location
5. Review README.md and CHANGELOG.md
6. Search for privacy-sensitive strings
7. Report hard failures first, then soft risks, then compliant items

Standard Answer Shape

When reporting packaging readiness, answer in this order:

1. State whether the project has blocking issues
2. List hard failures with file references
3. List soft risks or manual-review items
4. Confirm compliant items briefly
5. If asked to fix problems, make the smallest safe edits and re-check

Severity Model

Use this severity model for reviews:

• Blocking: upload or review is likely to fail
• Risk: likely acceptable technically, but may fail policy or manual review
• Improvement: not required, but would make submission clearer or safer

Examples of blocking issues:

• Missing required manifest fields
• Invalid or missing categories
• Missing icon file
• Icon too small or too large
• entry points to a nonexistent bundle
• README.md or CHANGELOG.md missing entirely
• Clear privacy leak in package contents

Examples of risk items:

• README exists but usage steps are too thin
• Changelog exists but release notes are sparse
• Icon ownership cannot be verified from repository evidence alone
• name uniqueness cannot be proven outside the current repository scope

Copyable Review Template

Packaging review result: blocking issues found.

Risks:
- `README.md` explains the feature, but in-product usage steps are still brief
- Icon ownership cannot be fully verified from repository contents alone

Compliant items:
- Required manifest fields are present
- `categories` is set
- Custom logo exists and meets size constraints
- `CHANGELOG.md` exists
- No obvious phone numbers or similar privacy data were found

Related Skills

• Use easyeda-extension-manifest for headerMenus, registerFn, and page-key details
• Use easyeda-extension-iframe-template when the extension still needs a working scaffold
• Use easyeda-extension-debugging if the package installs but the menu or runtime still fails