fix(release): keep pnpm-lock.yaml in sync through the changeset version bump#61
Merged
Merged
Conversation
…on bump Every release stalled because the changesets Version PR bumped the internal dep (create-bhono -> @etus/bhono) to a not-yet-published version, leaving the lockfile out of date, so the release workflow `pnpm install --frozen-lockfile` failed. - .npmrc: link-workspace-packages=true so internal deps resolve to the local workspace (link:../bhono-app) instead of a registry version that does not exist yet during the bump. - changeset:version now also runs `pnpm install --lockfile-only`, so the release PR carries an in-sync lockfile. - release.yml: changesets/action uses that script (version: pnpm run changeset:version) and gets NODE_AUTH_TOKEN so the lockfile refresh can resolve restricted @ETUS deps. npm publish (not pnpm) still publishes the range in package.json, so the published create-bhono keeps "@etus/bhono": "^x.y.0" — link-workspace-packages only affects resolution/lockfile, never the manifest.
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.
Problem
Every release stalled on
pnpm install --frozen-lockfileinrelease.yml. The changesets "Version Packages" PR bumps the internal depcreate-bhono → @etus/bhonoto a version that isn't published yet, but the action never updatespnpm-lock.yaml. So the lockfile says^0.2.0while the manifest says^0.3.0→ERR_PNPM_OUTDATED_LOCKFILE, and pnpm can't resolve the bumped version from the registry →ERR_PNPM_NO_MATCHING_VERSION. This is why the 0.3.0 release (and the prior #53/#55 runs) failed; 0.3.0 only shipped after a manual lockfile patch.Fix
.npmrc:link-workspace-packages=true— internal deps resolve to the local workspace (link:../bhono-app) instead of a registry version that doesn't exist during the bump. This is the load-bearing change.changeset:versionalso runspnpm install --lockfile-only— the Version PR now carries an in-sync lockfile.release.yml: the changesets action uses that script (version: pnpm run changeset:version) and getsNODE_AUTH_TOKENso the lockfile refresh can resolve restricted@etusdeps.npm publish(notpnpm) still publishes the range from package.json, so the publishedcreate-bhonokeeps"@etus/bhono": "^x.y.0"—link-workspace-packagesonly affects resolution/lockfile, never the manifest.Validation (throwaway-changeset test, locally)
Ran the exact script the CI calls with a minor changeset:
changeset:version→ bumped both to 0.4.0,create-bhonodep →^0.4.0(range, notlink:), lockfile resolved@etus/bhonotolink:../bhono-app, exit 0. (TheERR_PNPM_FETCH_404lines for@etus/bhono/@etus/authare non-fatal noise — pnpm tries the registry, then falls back to the workspace link;@etus/auth@0.8.0stays resolved.)pnpm install --frozen-lockfile --filter '@etus/bhono...'against the bumped lockfile → exit 0, "Lockfile is up to date". This is the step that was failing.Out of scope (operational, not code)
The
NPM_TOKENrepo secret should be a read-only token dedicated to the@etusscope (it was expired/over-scoped — I refreshed it with the dev publish token to unblock 0.3.0). Swap it for a dedicated read-only token when convenient; no code change needed.