Release Process

A release is publishable only when the same npm run release:verify command passes locally and in CI. The gate includes formatting, lint, TypeScript, runtime tests, type-surface tests, the dual build, package/export verification, browser/edge bundling, bundle-size budgets, and the locked public API contract.

CI layout

• Quality and API types: formatting, lint, typecheck, and declaration tests.
• Runtime matrix: Node 22 and 24 on Linux plus Node 22 on Windows.
• Packed artifact: build, ESM/CJS imports, tarball hygiene, publint, Are the Types Wrong, browser/edge bundles, size budgets, and API contract.
• Documentation: MDX/type generation and the production Next.js build.

Publishing

The release workflow runs only for a v* tag. It first requires the tag (for example v1.6.1) to match package.json, runs every release gate again, then publishes to npm with provenance and creates the GitHub release. A normal push to main cannot publish.

npm run release:verify
git tag v1.6.1
git push origin v1.6.1

Changesets remain the version/changelog mechanism for later releases. Bundle thresholds live in tooling/bundle-size-budgets.json; public subpaths and root declarations are locked in tooling/api-contract.json. Changing either contract should be an explicit review decision, not an incidental build result.

API keys and custom gateway URLs are never stored in fixtures or release configuration. Live smoke tests receive them only through process environment variables and must clean temporary state afterward.