Packaging and Installation

Build from the example plugin and keep one root manifest as the source of package identity. Its scripts generate the per-side manifests and output layout.

Manifest

This is the combined starter manifest shape. The minimum versions shown belong to the example; choose tested floors for your plugin.

{
  "id": "example_device_plugin",
  "name": "Example Device Plugin",
  "description": "A device driver and its operator tools.",
  "author": "Your team",
  "version": "2.0.0-beta.1",
  "minEngineVersion": "2.0.0-beta.1",
  "minInterfaceVersion": "1.0.0-pre_release",
  "contains_engine_plugin": true,
  "contains_interface_plugin": true
}

Change package.json and plugin.json versions together using the starter’s version script, for example npm version 2.0.0-beta.2 --no-git-tag-version. Do not raise a minimum version merely to match your plugin version: it describes the host API you require.

Build the package

npm ci
npm run verify
npm run package

package builds and verifies all enabled sides. An engine side requires CMake, a C++ toolchain, and VCPKG_ROOT pointing at a vcpkg checkout with the starter’s dependencies. An interface-only package does not need native build tools.

The release archive is plugin.zip. The starter wraps its output in a plugin/ folder:

plugin/
  engine/<id>/
    plugin.json
    bin/<native-library>
    ...                     # defaults, configs, and binary dependencies
  interface/<id>/
    plugin.json
    ui/index.js
    ...                     # UI assets
  files/                    # optional engine-root files

Disabled sides are omitted. npm run package-debug creates plugin-debug.zip with engine-debug/ instead of engine/. Use debug binaries only with a compatible debug engine. Native libraries must also match the host OS and architecture.

Install locally

For a local development installation, set the destination roots and let the starter copy the correct files:

$env:DARTWIC_ENGINE_DIR = 'C:\DARTWIC\engine'
$env:DARTWIC_INTERFACE_DIR = 'C:\DARTWIC\interface'
npm run deploy

Use your actual engine configuration root and interface plugin host root. You can instead copy deployment-settings.example.json to deployment-settings.json and set engine_dir and interface_dir. deploy-debug targets a debug engine; deploy:interface rebuilds and copies only UI.

For a manual install, stop the affected host before replacing loaded files, extract the archive, and copy each ID directory:

Each installed side needs its own valid plugin.json. Preserve the native bin/ and UI ui/ subdirectories and all dependencies. Do not place the entire ZIP or an extra plugin/engine/ wrapper inside the installed ID directory.

Start the engine and reload the interface. In Settings → Plugins, check the installed side, version, and any load error. Create a module instance only after its engine plugin is loaded. See Interface Plugins for the normal plugin-browser workflow.

Publish for the plugin browser

1. Commit the source and root plugin.json to a public GitHub repository. Include a README with setup, supported hardware, compatibility, and troubleshooting.
2. Build and verify the release package. Create a GitHub release for the same source version, with both plugin.json and plugin.zip as release assets. Keep the manifest in the tagged source too; browser hosts read it from the tag.
3. Submit a pull request adding your entry to data/plugin-registry.json. It is a JSON array; add an object like this inside the array:

{
  "id": "example_device_plugin",
  "name": "Example Device Plugin",
  "author": "Your team",
  "description": "A device driver and its operator tools.",
  "repo": "your-org/your-plugin-repository"
}

The registry points to your repository. The plugin browser resolves published releases, checks the manifest ID and minimum host versions, and selects compatible output. A source-only tag is useful as a developer starter but is not an installable plugin-browser release without the two assets.