Runtime distributions

Generated clients need their runtime packages installed as well as their own generated code. The supported distribution units are:

These names describe the intended registry packages. A successful local build does not mean a version exists in a registry. npm and PyPI publication remain disabled until maintainers configure trusted publishers and enable the release switches. Rust manifests retain publish = false; Rust publication requires a separate reviewed change. Before relying on registry installation, check that the version required by your generated package is available.

All runtime distributions use Apache-2.0 and include the actual license file. The generator's license is separate. npm packages ship compiled ESM, TypeScript declarations and explicit exports. @elysra/tungsten-runtime/node supplies Node adapters; the core and WebMCP import graphs stay free of Node builtins. The MCP runtime runs on Node and can import Node functionality. Browser WebMCP API availability depends on the host browser and is checked separately from package distribution.

For local development before registry publication, build the runtimes and set the generator's supported runtime path options to your local checkout. A source path is a development dependency; package releases use registry version ranges. The release checks also install all npm tarballs together into an isolated project, so the core peer is resolved from the packed artifact instead of a source link or an unpublished registry version.

Maintainers can reproduce the npm distribution check with make runtime-packages in the development repository. It checks version agreement, registry dependency declarations, exported JS and declaration files, Apache licenses, isolated package imports and the distributed browser import graph. The validated tarballs and checksums are retained for inspection. To check all runtime archives locally, run python release/runtime-artifacts.py; Python requires the pinned build and twine tools, and Rust verification compiles temporary packaged crates. The script builds a wheel and sdist, checks metadata, licenses and typing files, installs the wheel in an isolated environment, and packages the Rust workspace in a temporary copy without changing its committed publication switch.

The release workflow always checks npm packages, builds Python archives and rehearses Rust packaging. npm publishing uses the already validated archives, checks their checksums, and publishes the core runtime before its adapters. Only a real release with NPM_PUBLISH=true can publish npm packages, using GitHub's OIDC trusted publisher in environment npm. Missing registry publisher configuration fails the job; there is no stored-token fallback. Prereleases use the next npm dist-tag, and stable releases use latest. All archive versions must match the full release tag before the first upload; mismatched prerelease and stable package versions fail the publish step.

See Downloads for CLI installation and Browser integration for browser setup and capability checks.