fix(ci): move to pnpm 11, the version CI actually installs - #10
Merged
Conversation
CI went red on 2026-08-05 with nothing changed in the repo:
[ERROR] Cannot verify the identity of the @pnpm/exe.linux-x64 native
binary: it is missing from pnpm-lock.yaml
`RUN npm install -g pnpm` is unpinned, so each build installs whatever pnpm is
newest at that moment. The 08-03 build got pnpm 10; by 08-05 it got 11. pnpm 11
read `packageManager: pnpm@10.26.2`, tried to switch itself down to that version,
and refused because it couldn't verify that binary. The repo was untouched — only
upstream's release schedule changed.
Rather than pinning, this follows what CI installs: `packageManager` moves to
11.20.0. **The lockfile needs no changes** — not one line differs after
regenerating with pnpm 11, so no dependency versions move.
## Why the two other files change
pnpm 11 then failed on something else:
[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts:
@parcel/watcher, @swc/core, sharp
pnpm 11 turns "a dependency's build script was skipped" from a warning into a hard
error — supply-chain hardening: every script-running dependency needs a recorded
decision instead of silently executing.
All three are recorded as `false`, which **keeps today's behaviour**: these scripts
never ran under pnpm 10 either and the image has always worked (their native
binaries come from prebuilt per-platform packages). Setting them to `true` would be
a behaviour change — sharp might compile from source, which affects build time and
the artifact — and that doesn't belong in a "fix CI" commit.
The decision has to live in `pnpm-workspace.yaml`: since v11 pnpm no longer reads
settings from package.json's `pnpm` field. Confirmed the hard way — putting
`ignoredBuiltDependencies` in package.json changed nothing.
Which is also why the Dockerfile's COPY line grows a file. It copied only
package.json and pnpm-lock.yaml, so the config never reached the image and the
install kept failing with the same error — and that error says nothing about a
missing file, so this is worth a comment rather than rediscovering it later.
## Verification
Locally: `pnpm install --frozen-lockfile` succeeds under pnpm 11.20.0, and
`docker build --target builder` completes (`Done in 10s using pnpm v11.20.0`).
One thing this commit does **not** claim: `next build` now emits a
`Can't resolve 'supports-color'` warning (optional dependency of `debug`, reached
through axios). It is a warning, not an error, and the build completes. I could not
establish whether it predates this change — the successful 08-03 CI log is truncated
at 400KB before the build output, and the local A/B comparison couldn't be finished.
Worth a look if anything about axios logging misbehaves.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
What broke
CI went red on 2026-08-05 with nothing changed in the repo:
RUN npm install -g pnpmis unpinned, so each build installs whatever pnpm is newest at that moment. The 08-03 build got pnpm 10; by 08-05 it got 11. pnpm 11 readpackageManager: pnpm@10.26.2, tried to switch itself down to that version, and refused because it couldn't verify that binary against the lockfile.The repo was untouched — only upstream's release schedule changed. That's the nastiest failure mode: the first instinct is to blame the last commit, and the last commit is innocent. Confirmed the last change touched neither
package.jsonnorpnpm-lock.yaml, andnext buildpasses locally.The approach
Follow what CI installs rather than pinning against it:
packageManager→ 11.20.0.The lockfile needs no changes — regenerating with pnpm 11 produces a byte-identical file, so no dependency versions move.
Why two more files change
pnpm 11 then failed on something else:
pnpm 11 turns "a dependency's build script was skipped" from a warning into a hard error — supply-chain hardening: every script-running dependency needs a recorded decision instead of silently executing.
All three are recorded as
false, which keeps today's behaviour — these scripts never ran under pnpm 10 either and the image has always worked (their native binaries come from prebuilt per-platform packages). Setting them totruewould be a behaviour change (sharp might compile from source, affecting build time and the artifact) and doesn't belong in a "fix CI" commit. Easy to revisit deliberately.That decision has to live in
pnpm-workspace.yaml: since v11, pnpm no longer reads settings from package.json'spnpmfield. Confirmed the hard way — puttingignoredBuiltDependenciesin package.json changed nothing, the install failed identically.Which is also why the Dockerfile's
COPYline grows one file. It copied onlypackage.jsonandpnpm-lock.yaml, so the config never reached the image and the install kept failing with the same error — and that error says nothing about a missing file, hence the comment above the line.Verification
pnpm install --frozen-lockfilesucceeds under pnpm 11.20.0docker build --target buildercompletes:Done in 10s using pnpm v11.20.0One thing this PR does not claim:
next buildnow emits aCan't resolve 'supports-color'warning (optional dependency ofdebug, reached via axios). It's a warning, the build completes. I could not establish whether it predates this change — the successful 08-03 CI log is truncated at 400KB before the build output, and the local A/B comparison couldn't be finished. Flagging it rather than asserting it's harmless.🤖 Generated with Claude Code