ORCA-904: pin pnpm with a packageManager field - #65
Closed
presmihaylov wants to merge 1 commit into
Closed
Conversation
The repo declares engines.node but never which pnpm, so CI resolved a floating 10.x while contributors used whatever they had globally. pnpm 12 is current and --frozen-lockfile fails on 11+ against lockfileVersion 9. The field replaces the action-setup version input rather than sitting beside it: action-setup documents version as optional when packageManager exists, but not what happens when the two disagree.
presmihaylov
force-pushed
the
orca-904-pin-pnpm-packagemanager
branch
from
September 7, 2026 06:55
f41ce36 to
4e50cf7
Compare
Contributor
Author
|
Closing on Pres's call: not needed, CI works with the floating pnpm 10 and nothing depends on the pin. |
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.
Closes ORCA-904.
Why. The repo pins node but never pnpm. Both workflows install a floating
version: 10, so CI takes the newest 10.x while a contributor uses whatever pnpm they have.--frozen-lockfilefails on pnpm 11+ againstlockfileVersion: 9.0, and it reads as a broken lockfile, not a wrong toolchain.How.
version: 10input rather than sitting beside it.pnpm/action-setupthrowsMultiple versions of pnpm specifiedwhen the two disagree, so keeping both leaves a release workflow that fails on drift.pnpm --versionreports 10.34.5 in the repo with a global 11.5.1, and the gate passes.What. Three files, no dependency or lockfile change. Moving to pnpm 11 or 12 needs a lockfile migration, out of scope.