Improve security with npm staged publishing#301
Open
stijnvanhulle wants to merge 14 commits into
Open
Conversation
Replace the turbo-driven per-package release:stage scripts with a single recursive pnpm stage publish at the workspace root. A small scripts/release-stage.mjs reads .changeset/pre.json so staged releases inherit the active pre-mode tag (e.g. beta, rc) automatically. - root release:stage now runs 'pnpm stage publish -r --no-git-check --access public' - new scripts/release-stage.mjs orchestrates stage publish + changeset tag for CI - drop release:stage from all per-package package.json files - drop the release:stage turbo task
Review or Edit in CodeSandboxOpen the branch in Web Editor • VS Code • Insiders |
|
dosubot
Bot
added
the
size:S
The 'release' and 'release:canary' scripts in each packages/*/package.json referenced files that no longer exist (.github/canary.sh, scripts/build.js) and were not invoked from anywhere. Canary and stable publishes both run from the workspace root via changesets, so these per-package entries are dead. Remove them along with the orphaned turbo tasks.
The release-stage.mjs script already gates the GITHUB_OUTPUT write on the env var being set, so the same entry works for both local invocations and CI. Drop the duplicate.
Contributor
e18e dependency analysisNo dependency warnings found. |
The changesets/action would intercept staged mode whenever pending changesets exist (opening a Version PR instead of staging). Split the flow so: - version/publish modes keep using changesets/action - staged mode skips the action entirely and runs 'pnpm release:stage' directly against the already-versioned tree Promote MODE to a job-level env, drop the resolve-command shim, and key the canary/notify gates on the stage step's staged output.
More templates
@kubb/plugin-client
@kubb/plugin-cypress
@kubb/plugin-faker
@kubb/plugin-mcp
@kubb/plugin-msw
@kubb/plugin-react-query
@kubb/plugin-redoc
@kubb/plugin-swr
@kubb/plugin-ts
@kubb/plugin-vue-query
@kubb/plugin-zod
commit: |
Strip the mode selector out of the workflow. The only publish action is 'pnpm release:stage', wired in as the publish command on changesets/action. The action handles the rest: - pending changesets present (push or workflow_dispatch) -> opens the 'Version Packages' PR - no pending changesets -> runs the staged publish workflow_dispatch stays available as a manual trigger (no inputs) so a maintainer can kick off Version PR creation on demand. Canary, test, and codecov behaviors are unchanged.
Stage is the only release path now, so the qualifier is noise. Rename the npm script and update the workflow + comment to call 'pnpm release'.
Closes the two gaps in the stage flow: - pnpm stage publish's output doesn't match the '🦋 New tag:' format changesets/action scans for, so no GitHub Releases were ever created. Capture pnpm's --json output, parse the staged packages, and emit the marker per package so the action picks them up and creates a Release. - 'changeset tag' produces local annotated tags, but nothing pushed them. Push the tags to origin after they're created so the GitHub Release has a remote tag to anchor to. Discord notify already keys off steps.changesets.outputs.staged, which the script sets, so it stays green.
dosubot
Bot
added
size:M
If pnpm stage publish skips every package (because their current versions are already on npm — typical for a feature merge that didn't bump anything), we shouldn't signal staged=true. That lets the canary step fire as intended on ordinary main pushes.
Drops the 'release' npm script alias. The workflow now calls 'node scripts/release.mjs' as the publish command on changesets/action.
Every push to main without a stage now publishes each workspace package at 0.0.0-YYYYMMDDTHHMMSSZ under the canary dist-tag. The 0.0.0 base sorts below any real release in semver, so canaries can't shadow stable or pre-release versions on the latest tag. Also drops the per-package date call — one timestamp is shared by all packages in a given push so the canary set is internally consistent.
stijnvanhulle
changed the title
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
2 participants
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.
Summary
Adds proper support for npm staged publishing by leaning on
pnpm stage publish(pnpm 11.3+).Previously each package carried its own
release:stagescript and the root coordinated them through turbo. That's redundant once pnpm stages workspace packages recursively.release:stageis nowpnpm stage publish -r --no-git-check --access public.scripts/release-stage.mjsdrives CI: it reads.changeset/pre.json, forwards the active pre-tag (e.g.beta,rc) via--tag, then callschangeset tagand signalsstaged=trueto$GITHUB_OUTPUT.release:stagescript from every package and the matching turbo task — there's a single source of truth now.Changesets itself doesn't yet expose
changeset publish --stage(tracked in changesets#2025); this keeps the existingstagedworkflow mode but reroutes it through the simpler script.Test plan
stagedmode against thebetabranch and confirm packages land in npm's staging area with thebetatag.pnpm stage approve(ornpm stage approve) and confirm promoted versions appear onlatest/betaas expected.Generated by Claude Code