fix(ci): keep lockfile maintenance from bumping manifest ranges - #73
Merged
Conversation
pnpm 11 update --lockfile-only also rewrites package.json ranges and the lockfile's specifier records; committing only the lockfile shipped a specifier mismatch that fails frozen installs (taizn#64, run 32329772704). --no-save keeps the manifest and specifier records intact while still refreshing direct and transitive resolutions in range, proven on taizn manifests (ws 8.21.3, @types/node 26.2.0, postcss 8.5.26 with specifiers unchanged; frozen install passes). Also assert the refresh touches nothing but pnpm-lock.yaml. Refs putdotio/putio-frontend#29 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adjusts the lockfile-maintenance GitHub Action to refresh pnpm-lock.yaml on pnpm 11 without accidentally rewriting manifest ranges/specifiers, preventing --frozen-lockfile install failures after a lockfile-only commit.
Changes:
- Add
--no-savetopnpm update --lockfile-only -rto keeppackage.jsonand lockfile specifier records stable. - Add a “tripwire” step intended to fail the workflow if files other than
pnpm-lock.yamlare modified during the refresh.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
putio-releaser Bot
added a commit
that referenced
this pull request
Aug 20, 2026
## [1.6.4](v1.6.3...v1.6.4) (2026-08-20) ### Bug Fixes * **ci:** keep lockfile maintenance from bumping manifest ranges ([#73](#73)) ([9067ffd](9067ffd)), closes [taizn#64](putdotio/taizn#64) [putdotio/putio-frontend#29](putdotio/putio-frontend#29)
Contributor
|
🎉 This PR is included in version 1.6.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
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
The first end-to-end lockfile-maintenance run produced a PR that fails frozen installs (taizn#64, run 32329772704):
specifiers in the lockfile don't match specifiers in package.json.Mechanism (reproduced on pristine taizn manifests): untargeted
pnpm update --lockfile-only -ron pnpm 11 rewritespackage.jsonranges and the lockfile's specifier records for direct deps with newer in-range versions; the workflow committed onlypnpm-lock.yaml, guaranteeing the mismatch.Fix: add
--no-save— it keeps the manifest and specifier records at their committed values while still refreshing direct and transitive resolutions in range. Proven on the same scratch:ws8.21.3,@types/node26.2.0,postcss8.5.26 resolved with specifiers unchanged (^8.21.0/^26.1.0), andpnpm install --frozen-lockfilepasses. The untargeted--no-saveform is not affected by the pnpm/pnpm#12744 no-op (that bug is specific to targetedpkg@versionspecs).Also adds a tripwire step failing the run if anything beyond
pnpm-lock.yamlis dirty after the refresh.Verification
Notes
Refs putdotio/putio-frontend#29