Releases #

@nibling/kernel and @nibling/npm-gateway are published to npm. Every other package is private and is never versioned or published.

Record a change #

Add a changeset with any change to a public package that users will notice:

pnpm changeset

This writes a Markdown file here. It names each changed package, its semver bump, and a one-line CHANGELOG entry. Commit it with the change.

Release #

Tangled spindles can't push commits or open pull requests, so a maintainer versions packages locally:

On an up-to-date main, run pnpm release:version. It applies the pending changesets, bumps versions and internal dependency ranges, writes each package's CHANGELOG.md, and updates the lockfile.
Review the diff, then commit it as Version packages.
Run pnpm changeset tag to tag each new version (for example, @nibling/kernel@0.1.0).
Run git push --follow-tags. On that push, .tangled/workflows/release.yml runs pnpm release:stage (scripts/stage-release.mjs), which stages each public package whose version is neither on npm nor already staged. A push that bumped nothing stages nothing, so a failed run can be retried from the pipelines page.
Approve the staged versions with 2FA, on npmjs.com under Staged Packages (one prompt approves a batch) or with npm stage approve <id> (npm 11.15 or later; npm stage list shows the ids).

CI never publishes directly. npm's trusted publishing has no Tangled provider, and tokens that bypass 2FA lose direct publishing in 2027. The NPM_TOKEN secret does not bypass 2FA, so it can stage and nothing more. A package's first staging publishes a 0.0.0-stage placeholder until its first approval.

Deploys #

.tangled/workflows/deploy.yml deploys main on every push. packages/app goes to nibling.dev and packages/api goes to api.nibling.dev. Deploys are not tied to releases.