Release
Prepare
- Confirm every consumer-visible package change has the correct
.changeset/*.mdfile. - Run
pnpm exec changeset statusand review the affected packages and bump levels. - Run
pnpm verify. - Send the source change and Changeset through normal review. The Release workflow maintains the rolling
chore: version packagespull request.
Ship
Do not merge or publish unless the user explicitly says to ship.
- Review the generated versions, changelogs, and commit in the rolling version pull request.
- Read its current head SHA. Require a successful
workflow_dispatchrun ofVerifywith the same head SHA. A successful run for an older SHA does not qualify. - Merge only the generated version pull request.
- Monitor the resulting Release run through publish and tag reconciliation.
- For every expected version, run
npm view <package>@<version> versionand confirm the expected package tag resolves to the release commit.
Recovery
- Keep the generated version commit on
main. Inspect every expected package version in npm and every expected package tag before retrying. - For versions absent from npm, rerun the failed Release workflow for the same commit. A partial retry skips versions already accepted by npm.
- If npm accepted a version but its tag is missing, use that version's npm provenance to prove the exact release commit. Confirm the package manifest at that commit has the same name and version and that the expected
<package>@<version>tag is absent. Create only that ref at the proven commit. - If provenance does not prove the commit, stop. Do not guess, create another bump, republish, or publish locally.
Preconditions
- GitHub Actions can create pull requests with
GITHUB_TOKEN. - The GitHub
npmenvironment allows deployments only frommain. - Each npm package trusts this repository,
.github/workflows/release.yml, and thenpmenvironment. - The Release workflow's
GITHUB_TOKENcan create the expectedrefs/tags/<package>@<version>refs.