chore(CI): Using pnpm 11.#3385
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughUpdates root ChangesPackage manager + Release Workflow
Sequence Diagram(s)sequenceDiagram
participant ActionsRunner
participant pnpm
participant Git
ActionsRunner->>pnpm: run "pnpm -F <workspace> version <kind> [--preid beta]"
pnpm->>Git: create commit and tag
ActionsRunner->>Git: run "git push --follow-tags"
Git->>ActionsRunner: push result
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
No new issues found.
TL;DR — Bumps the root packageManager field from pnpm@10.33.4 to pnpm@11.0.9. CI is green across the full Node matrix and the bump propagates to all workflows automatically.
Key changes
- Bump
packageManagertopnpm@11.0.9— Single-line change in rootpackage.json; the SHA-512 integrity matches the published artifact and Node>=22.13requirement is already satisfied byengines.node.
Summary | 1 file | 1 commit | base: master ← use-pnpm11-b
pnpm 11 propagates without workflow edits
Before: Root pinned to
pnpm@10.33.4; CI implicitly resolved the same version viapnpm/action-setup@v6readingpackageManager.
After: Root pinned topnpm@11.0.9; the sameaction-setup@v6mechanism picks up v11 with no workflow change.
Despite the chore(CI) prefix, no .github/workflows/*.yml file needs to be touched — every job uses pnpm/action-setup@v6 without a version: input, so they all read the root packageManager field. The matrix builds (Node 22.19.0, 22.x, 24.0.0, 24.x, 26.0.0, 26.x) and the publish, dependencies, headers, and bump workflows all consume the new pin transparently.
v11 default flips landed cleanly
Before: v10 defaults —
strictDepBuilds: false,blockExoticSubdeps: false,minimumReleaseAgeStrict: false(even withminimumReleaseAgeset).
After: v11 defaults — all three flip totrue, with the last being implicit wheneverminimumReleaseAgeis configured.
The PR description already calls out the supply-chain default tightening, and the existing overrides for @scarf/scarf and lightningcss plus the curated minimumReleaseAgeExclude list were sufficient — pnpm install in CI did not require any new entries in allowBuilds or trigger an ERR_PNPM_IGNORED_BUILDS. Worth keeping in mind for future PRs: a freshly published transitive that isn't in minimumReleaseAgeExclude and isn't yet 48h old will now hard-fail resolution under v11 where v10 would have fallen back silently.
Claude Opus | 𝕏
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/bump.yml (1)
38-38:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate or remove stale comment.
The comment references "bumpp internally" but this workflow no longer uses bumpp—it now uses pnpm's native
versioncommand. Either update the comment to reflect whetherpnpm versionneeds the full git history, or remove it iffetch-depth: 0is no longer necessary.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/bump.yml at line 38, The comment "for git describe --tags (used by bumpp internally)" is stale because the workflow no longer uses bumpp; update or remove it: either change the comment to explain why fetch-depth: 0 is required for the current step (e.g., "for git describe --tags used by pnpm version" if pnpm requires full history) or delete the comment entirely if pnpm's `version` does not need full git history; update the line containing "fetch-depth: 0" and its adjacent comment accordingly so it accurately reflects current tooling (reference symbols: fetch-depth: 0, pnpm version, bumpp).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/bump.yml:
- Line 38: The comment "for git describe --tags (used by bumpp internally)" is
stale because the workflow no longer uses bumpp; update or remove it: either
change the comment to explain why fetch-depth: 0 is required for the current
step (e.g., "for git describe --tags used by pnpm version" if pnpm requires full
history) or delete the comment entirely if pnpm's `version` does not need full
git history; update the line containing "fetch-depth: 0" and its adjacent
comment accordingly so it accurately reflects current tooling (reference
symbols: fetch-depth: 0, pnpm version, bumpp).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 57a0c78a-d512-466d-8ff1-836cbede78ea
📒 Files selected for processing (1)
.github/workflows/bump.yml
There was a problem hiding this comment.
Caution
This PR introduces two regressions in .github/workflows/bump.yml that, taken together, make the Bump workflow a no-op as far as the remote is concerned: the version change in package.json is computed but never committed, never tagged, and never pushed. Reproduced locally against pnpm@11.0.9.
Reviewed the following changes:
- Bumped root
packageManagertopnpm@11.0.9(covered in the prior review; CI matrix stayed green). - Replaced
pnpm dlx bumpp@10with nativepnpm -F <ws> version <kind>in the Bump workflow.
Claude Opus | 𝕏
|
There was a problem hiding this comment.
No new issues. Reviewed the following changes:
- Dropped
-F ${{inputs.workspace}}from thepnpm versioninvocation and setworking-directory: ${{inputs.workspace}}on the step, sopnpm versionruns in non-recursive mode and creates the commit and tag. - Added an explicit
Push commit and tagstep runninggit push --follow-tagsto publish the new commit and tag to the remote.
This is exactly the shape suggested in the prior review and resolves both regressions called out against 455a02d.
Claude Opus | 𝕏
There was a problem hiding this comment.
No new issues. Reviewed the following changes:
- Simplified the
npm-publish.ymlpublish step topnpm -F <workspace> publish ..., dropping the now-unnecessaryexec pnpm publishindirection. Under pnpm 11,pnpm publishis implemented natively (no longer delegating to npm) and documents--filteras a first-class option, so the new invocation is the supported idiom and equivalent in behavior — provenance still works since the job already grantsid-token: write.
Claude Opus | 𝕏

instead of #3375
Summary by CodeRabbit