Releasing an adapter

Adapters and the Adapter SDK have separate versions. Pin the SDK package version you tested; the host checks ADAPTER_API_VERSION (or the legacy sdkVersion marker) rather than equating it with npm SemVer.

Source builds

A source adapter provides package.json and src/adapter.ts, with an optional dsui.browser entry for custom browser components. DSUI installs dependencies, bundles the server entry and starts an isolated adapter host. Ordinary npm and native dependencies are supported by this source-build path.

adapters:
  example:
    source: local
    path: ./examples/example-adapter

Run DSUI from the repository root for the relative path above. Git source builds also accept a repository, ref and optional package path. Review source before configuring it; lifecycle scripts are disabled but source builds are trusted code.

Prebuilt artifacts

The prebuilt npm installation path uses a pinned package version and tarball SRI. A prebuilt artifact includes the adapter manifest and server bundle, plus a browser bundle for custom components. Follow the manifest and integrity contract enforced by the host; these requirements differ from the source-build path.

adapters:
  example:
    package: "@your-org/dsui-adapter-example"
    version: "1.0.0"
    integrity: "sha512-..."

See the complete example and the host’s installation schemas.

SDK releases

Adapter SDK uses its own npm package, changelog and adapter-sdk-vX.Y.Z tags. Its technical UI dependency is published first with the same version. SDKs ship TypeScript source, types, CSS and browser subpaths for Bun and TS-aware bundlers.

See release policy for versioning, Changesets and CI. Product releases remain separate and publish both npm and Docker distributions.