chore(deps): move pnpm overrides to pnpm-workspace.yaml - #62
Conversation
The transitive security overrides lived in a `pnpm` field in package.json. pnpm 10.33 reads that, so they work today — but pnpm 11 ignores the field outright and SILENTLY, with no warning or error. `engines.pnpm` is ">=10", so a pnpm 11 bump is permitted and would leave every override inert while the repo still looked patched. A security control that fails silently is worse than an absent one. Moved all ten overrides to pnpm-workspace.yaml, which both pnpm 10 and 11 honour. Verified behaviour-preserving: pnpm-lock.yaml is byte-identical after the move, and its `overrides:` block still records all ten. Adds a CI guard so this cannot regress: it fails if a `pnpm` field reappears in package.json, if the overrides block goes missing, or if any declared override is absent from the resolved lockfile — i.e. declared but not taking effect. Tested all three failure modes plus the passing case. Verified the overrides are load-bearing rather than decorative: removing them and re-resolving reintroduces sharp 0.34.5 (high, < 0.35.0) and an extra svgo 4.0.2. With them, every package resolves to a single version at or above its advisory floor.
|
Warning Review limit reached
Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
This PR successfully migrates pnpm overrides to ensure forward compatibility with pnpm 11. The approach is sound: moving security-critical overrides from the silently-ignored package.json location to pnpm-workspace.yaml, which both pnpm 10 and 11 honor. The byte-identical lockfile confirms behavior preservation, and the CI guard prevents regression by enforcing that overrides remain in the correct location and take effect in the resolved dependency tree.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
1 participant
The transitive security overrides lived in a
pnpmfield in package.json. pnpm 10.33 reads that, so they work today — but pnpm 11 ignores the field outright and silently, with no warning or error.engines.pnpmis">=10", so a pnpm 11 bump is permitted and would leave every override inert while the repo still looked patched.A security control that fails silently is worse than an absent one, so this removes the latent trap rather than relying on nobody bumping pnpm.
Change
All ten overrides moved to
pnpm-workspace.yaml, which both pnpm 10 and 11 honour — verified empirically with pnpm 10.33 before making the change (a probe with the override only inpnpm-workspace.yamlresolvedsvgo@3.3.4, not the requested3.3.3).Behaviour-preserving:
pnpm-lock.yamlis byte-identical after the move, and itsoverrides:block still records all ten.The overrides are load-bearing, not decorative
Proven by control test — strip them, re-resolve, and vulnerable versions come back:
0.35.30.34.5,0.35.33.3.43.3.4,4.0.2CI guard so this cannot regress
Fails the build if a
pnpmfield reappears in package.json, if the overrides block goes missing, or if any declared override is absent from the resolved lockfile — i.e. declared but not actually taking effect.Tested all three failure modes plus the passing case:
Verification
pnpm install --frozen-lockfileOK · build green · node 2/2 · ruby 5/5 · homebrew + scoop validators pass.