fix(client): let pnpm 10+ find the security overrides again - #7826
fix(client): let pnpm 10+ find the security overrides again#7826JacobWoodson wants to merge 1 commit into
Conversation
"pnpm install --frozen-lockfile" fails on any clean checkout or worktree with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH on "overrides", so nobody running a current pnpm can install the frontend dependencies. This is not lockfile drift. The "overrides:" block in pnpm-lock.yaml matches client/package.json entry for entry, all fourteen. pnpm 10.6+ stopped reading the "pnpm" field in package.json, so a current pnpm sees zero overrides while the lockfile records fourteen and refuses the frozen install. CI pins pnpm 9, which still reads the old location, so CI has stayed green and masked the split. Regenerating the lockfile is the trap, not the fix: under pnpm 11 it strips all fourteen security pins and then breaks CI with the mirror-image mismatch. pnpm-lock.yaml is deliberately untouched here. Add client/pnpm-workspace.yaml carrying the same overrides in the location pnpm 10.6+ actually reads. package.json keeps its copy so pnpm 9 -- and therefore CI -- is entirely unaffected. The duplication is deliberate and temporary; collapsing it to a single source of truth also requires pinning the pnpm version across the workflows, which touches protected surfaces and needs a maintainer-owned security and release review, so it is kept out of this change. The "packages" entry is required rather than decorative: pnpm 9 treats the presence of this file as a workspace root and aborts with "packages field missing or empty" without it. Omitting it would have broken every CI job. Also allowlist the esbuild and workerd build scripts. pnpm 9 runs every dependency's install scripts; pnpm 10+ blocks them unless allowlisted, and those two ship the platform binaries vite/vitest and wrangler need at build time. pnpm 9 has no such gate and ignores the key. Verified on both majors against the unchanged lockfile: pnpm 9.15.9 and pnpm 11.13.0 each complete "pnpm install --frozen-lockfile" and resolve the same 778-package tree, with normal node_modules layout and zero lockfile drift from either. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 33 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Deferred by maintainer intake policy — not ignored. This current head ( A maintainer must explicitly take this PR or add a local frontend-review exception before it can receive substantive review. The defer label is a routing marker only, not a verdict on the change. |
"pnpm install --frozen-lockfile" fails on any clean checkout or worktree
with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH on "overrides", so nobody running a
current pnpm can install the frontend dependencies.
This is not lockfile drift. The "overrides:" block in pnpm-lock.yaml
matches client/package.json entry for entry, all fourteen. pnpm 10.6+
stopped reading the "pnpm" field in package.json, so a current pnpm sees
zero overrides while the lockfile records fourteen and refuses the frozen
install. CI pins pnpm 9, which still reads the old location, so CI has
stayed green and masked the split.
Regenerating the lockfile is the trap, not the fix: under pnpm 11 it
strips all fourteen security pins and then breaks CI with the mirror-image
mismatch. pnpm-lock.yaml is deliberately untouched here.
Add client/pnpm-workspace.yaml carrying the same overrides in the location
pnpm 10.6+ actually reads. package.json keeps its copy so pnpm 9 -- and
therefore CI -- is entirely unaffected. The duplication is deliberate and
temporary; collapsing it to a single source of truth also requires pinning
the pnpm version across the workflows, which touches protected surfaces
and needs a maintainer-owned security and release review, so it is kept
out of this change.
The "packages" entry is required rather than decorative: pnpm 9 treats the
presence of this file as a workspace root and aborts with "packages field
missing or empty" without it. Omitting it would have broken every CI job.
Also allowlist the esbuild and workerd build scripts. pnpm 9 runs every
dependency's install scripts; pnpm 10+ blocks them unless allowlisted, and
those two ship the platform binaries vite/vitest and wrangler need at build
time. pnpm 9 has no such gate and ignores the key.
Verified on both majors against the unchanged lockfile: pnpm 9.15.9 and
pnpm 11.13.0 each complete "pnpm install --frozen-lockfile" and resolve the
same 778-package tree, with normal node_modules layout and zero lockfile
drift from either.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com