ReadAware

Publishing a plugin

The public plugin repository hosts marketplace packages and accepts changes through pull requests. Use its current contribution instructions and validator when preparing a submission.

Match the app you support

The development catalog can be ahead of the latest released app. The repository's types/host-capabilities.json describes that release, and its validator rejects requires ranges the release cannot satisfy. A package that needs a new capability must wait for a compatible host release; changing only minAppVersion does not create the missing API.

Use the Capabilities Explorer to inspect methods and versions, then declare the smallest compatible set you have actually tested.

Make the package reviewable

Commit manifest.json, readable source, the built self-contained main.js, and required runtime assets. Keep the folder name equal to the manifest ID. Do not load remote executable code or depend on files outside the package.

tree
plugins/my-plugin/
  manifest.json
  main.js
  package.json
  src/main.ts
  src/main.test.ts
  assets/

Check behavior and authority

  • Explain the feature, its entry points, and why each permission is needed.
  • Declare exact Settings grants and required network origins. Explain which data goes to external services.
  • Test book scope, absent permissions, cancellation, disable/re-enable, and the actual desktop UI.
  • Keep activation declarative and migrations storage-only.
  • Check private data retention, quotas, and cleanup of active resources.
  • For updates, exercise an existing installation with realistic data, including a failed migration and recovery.

The local manifest preview helps identify compatibility and authority mistakes. It does not replace the repository validator, desktop testing, or review.

Build and submit

Run the public repository's checks from its root; bun run check is what CI runs on your pull request:

bash
bun install
bun run build
bun run check

Add the matching registry entry according to the repository's current schema and ordering. Open a pull request describing the final behavior, tested app and capability versions, private data, external services, and permission changes. Include reproducible verification steps.

Updates

Bump the package version in the manifest and registry. Change schemaVersion only for a private-data schema change, with its migration in the same package. A request for more authority needs a clear explanation and a usable refusal path.

Signing, publisher identity, package integrity, review provenance and revocation are separate distribution concerns. State the controls that actually apply to the package; Worker isolation alone is not a guarantee about arbitrary code.

Build a plugin · API reference