ci: run the package check in CI, and document how a release happens - #245
Merged
Conversation
The 2.6.0 release failed on a gate CI does not run. check:package resolves the manifest exports and every import written in the README against the packed tarball, and it lived only in the release job, so a README documenting a subpath that went out with TanStack passed every check on the PR and stopped the publish instead. npm forbids replacing a published version, so a gate that fires only during a release costs a version number when it trips rather than a re-run. Running it in CI is the cheap place to fail. docs/releasing.md writes down what the workflow already does: how the version is derived from conventional commits, the two recovery modes, why publishing uses OIDC with no token in the repository, and what to do when a release fails. The 2.6.0 failure is recorded there as the worked example, since a merged PR and a published version disagreeing is the confusing part.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #244, which fixed the README but not the reason it reached the release job at all.
The gap.
check:packageresolves the manifest's exports and every import written inREADME.mdagainst the packed tarball. It ran only inRelease, so a README documentingprimitives/virtualizer(removed with TanStacksolid-virtual) passedcheck,tsc,build,test,check:apiandsmokeon the PR, then stopped the 2.6.0 publish.npm forbids replacing a published version, so a gate that fires only during a release costs a version number when it trips rather than a re-run. Moved forward to CI, right after Consumer Smoke since both need the built tarball.
The docs.
docs/releasing.mdwrites down what the workflow already does but nothing outside it stated: how the version is derived from conventional commits, the two recovery modes when a release half-finishes, why publishing uses Trusted Publishing/OIDC with noNPM_TOKENin the repo, which gates run and why they run twice, and what to do when a release fails. Linked from the README's documentation table.The 2.6.0 failure is recorded there as the worked example, since "master says 2.6.0 but npm serves 2.5.0" is the genuinely confusing part.
bun run check:package: passes, 926 files.🤖 Generated with Claude Code