中文
Package, install and publish plugins

Package, install and publish plugins

Build signed, updatable packages and publish platform variants

Complete project creation first. The generated build.ps1 supports Check, Build, Keygen and Pack. It reads the project's configuration, temporarily sets cross-compilation variables and restores them. It does not publish automatically.

Keep a stable author key

Create an Ed25519 key outside the project:

./build.ps1 -Action Keygen -PublisherKey E:/private/plugin-keys/my-plugin.key

Keygen refuses to overwrite an existing key. Reuse the key for later releases; only its public key belongs in the package.

Compile and package

./build.ps1 -Action Check
./build.ps1 -Action Build -Architectures amd64
./build.ps1 -Action Pack -PublisherKey E:/private/plugin-keys/my-plugin.key

Pack tests first, builds Windows amd64 and arm64, and uses packaging.Write to produce .ynp files in dist/. These are platform variants of the same package/version. Keep their business contracts consistent.

Windows payloads use -ldflags=-H windowsgui while communicating through inherited standard handles. Preserve this setting. A package contains contracts, implementation manifests, signatures, executables, yotta-plugin.json and optional companions/resources. The public packager calculates sizes and hashes and signs the archive. The high-level Process API does not become a Wasm packager by substituting a .wasm payload.

Install and verify

  1. Import the matching .ynp in Settings → Plugins.
  2. Restart the App to load the new plugin generation.
  3. Add and run its nodes; check outputs, errors and cancellation.
  4. For panels, check companion startup, snapshots, interaction and shutdown.

Plugin settings support enabling, disabling, updating, restoring a previous version, uninstalling and companion control. Saved state may differ from the version loaded by the current App process. Active runs retain package identities and can block lifecycle changes until they finish. Uninstalling preserves workflows, which need their dependency restored before use.

Diagnose installation failures from the host error, including integrity, author identity, API/platform compatibility and contracts. Fix and rebuild source metadata; do not edit a signed archive.

Publish and update

Use Hub's /creator/plugins entry with the real publisher namespace, platform variants sharing a Package ID/version, and your name, description, business category, tags, instructions and release notes. The platform derives system compatibility and functionality from verified contributions: nodes, maps, position sources and panels. A package can provide several functions; a map-only package need not contain nodes.

Position sources use positionsource.Contribution in packaging.Descriptor.PositionSources, with stable contribution identity and declared provider paths. Keep those IDs stable across updates; ports and display names do not replace them. A settings panel, when declared, belongs to the same companion. Map display and position-source selection remain separate concerns.

For an update, change plugin.json.version, preserve namespace, slug and author key, and keep published versions immutable. Node semantic changes require a separate compatibility decision; also preserve panel, field and component identities. Resolve, test and rebuild when changing the SDK.

Verify first install, upgrade, older workflow loading, disable/restart and restoring a previous version. Keep test profiles and keys separate from active App data. The current marketplace supports multiple real package versions; author history management and GitHub Release source binding are not prerequisites of the present publishing flow.