Upgrade pnpm to v11 📦🆙#71
Conversation
- Bump pnpm/action-setup version in CI from 9 to 11 - Pin pnpm 11.1.1 via packageManager field - Regenerate lockfile with pnpm 11 - Allow build scripts for esbuild, sharp, and unrs-resolver (pnpm 11 ignores postinstall scripts by default)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
|
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:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughPin pnpm@11 in package.json, update GitHub Actions jobs to use pnpm v11 and Node.js 24, enable workspace builds for esbuild/sharp/unrs-resolver, and add Vercel installCommand/buildCommand that invoke Changespnpm Upgrade to Version 11
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 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 |
pnpm/action-setup@v5 errors out when both the workflow's `version` input and the `packageManager` field are set. Drop the workflow input so the action reads the pinned version from package.json.
pnpm 11 requires Node.js ≥ 22.13. Bump the CI runner to Node 24 to match the `engines.node` field in package.json.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
Two follow-ups before merging: (a) package.json still carries a pnpm.overrides block that no longer appears in the regenerated lockfile — likely to trip --frozen-lockfile in CI, and (b) the workflow's version: 11 input duplicates the Corepack packageManager pin. Both are easy to resolve; the allowBuilds syntax itself is correct for pnpm v11.
TL;DR — Bumps pnpm from v9 to v11 across CI, pins the exact version via the packageManager field, regenerates the lockfile, and adds pnpm-workspace.yaml to opt three native packages back into running their install scripts (pnpm v10+ skips them by default).
Key changes
- Pin
pnpm@11.1.1via Corepack — addspackageManagerfield with sha512 integrity so all environments resolve to the same patch. - Bump
pnpm/action-setupinput from9to11— three CI jobs updated in lockstep. - Regenerate
pnpm-lock.yaml— new lockfile under pnpm 11, withlibc:annotations on Linux variants and a refreshed vitest peer-key signature. - Add
pnpm-workspace.yaml— uses the v11allowBuilds:map to permitesbuild,sharp, andunrs-resolverinstall scripts (these replaced the legacyonlyBuiltDependenciesarray in v11).
Summary ｜ 4 files ｜ 1 commit ｜ base: main ← upgrade/pnpm-11
Lockfile drops overrides while package.json still declares them
Before:
pnpm-lock.yamlcarried anoverrides:preamble matchingpackage.json#pnpm.overridesfor@types/reactand@types/react-dom.
After: the lockfile'soverrides:block is gone (grep returns zero matches), butpackage.json:93-98still declares the samepnpm.overrides.
pnpm classically rejects this mismatch with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH under --frozen-lockfile. The PR's local test plan reports success, but the CI checkbox is still unchecked. Since @types/react@19.2.14 and @types/react-dom@19.2.3 are already pinned to those exact versions as direct devDependencies (no caret) on package.json:80-81, the cleanest resolution is to delete the now-redundant pnpm.overrides block entirely rather than re-run regeneration.
Action version input duplicates the Corepack pin
Before: workflow specified
pnpm/action-setup@v5with: version: 9and there was nopackageManagerfield.
After: thepackageManagerfield pinspnpm@11.1.1+sha512..., but the workflow still passesversion: 11.
Per the pnpm/action-setup README, the version input is optional when packageManager is set in package.json. Keeping both means the action installs whatever floats at 11.x instead of the exact pinned 11.1.1, defeating the integrity-checked pin. Drop the version line from all three jobs.
Note: 1 inline comment(s) dropped because they did not anchor to lines inside the PR diff:
package.json:93-98(RIGHT) — line 98 (RIGHT) is not inside a diff hunk
Claude Opus ｜ 𝕏
| uses: pnpm/action-setup@v5 | ||
| with: | ||
| version: 9 | ||
| version: 11 |
There was a problem hiding this comment.
With packageManager: pnpm@11.1.1+sha512... now pinned in package.json, the version input here is redundant and can resolve to a different 11.x patch than the integrity-checked pin. Per the pnpm/action-setup README the field is optional when packageManager is set — drop it (here and in the two other jobs at lines 48 and 73) so Corepack consumes the exact pinned version.
| version: 11 | |
| uses: pnpm/action-setup@v5 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1a3cd00525
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "name": "domain-digger", | ||
| "version": "0.1.0", | ||
| "license": "AGPL-3.0-only", | ||
| "packageManager": "pnpm@11.1.1+sha512.d1fdf5f73c617b64fa1a56a81c3c8dfe0e966e33a6010aa256b517ae77be21d93e05affc0de1a83b0e4f29d569f68b446ae8f068cd7247c0bb3df0fb4d7bdf9a", |
There was a problem hiding this comment.
Pinning pnpm to v11 here changes how configuration is loaded, but this commit leaves the existing package.json pnpm.overrides in place; pnpm 11 no longer reads settings from the pnpm field in package.json, so those overrides are silently ignored. That means future installs/updates can resolve dependency versions differently than intended (and drift from previous behavior under pnpm 9), especially for the @types/react and @types/react-dom constraints currently kept as overrides. Move these overrides into pnpm-workspace.yaml under overrides: as part of the upgrade.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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/test.yml (1)
25-29:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUpdate Node.js version to match package.json requirement.
The workflow uses Node.js 20, but
package.jsonspecifies"node": "24"in the engines field. Testing with a different Node version than required could hide compatibility issues.Update all three jobs (formatting, linting, tests) to use Node.js 24.
📦 Proposed fix
- - name: Setup Node.js 20 + - name: Setup Node.js 24 uses: actions/setup-node@v6 with: - node-version: 20 + node-version: 24 cache: pnpmApply the same change to the linting job (lines 50-54) and tests job (lines 75-79).
🤖 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/test.yml around lines 25 - 29, CI is using Node.js 20 in the workflow's setup-node step; update the node-version from 20 to 24 for all three jobs (formatting, linting, tests) by changing the uses: actions/setup-node@v6 block where node-version: 20 to node-version: 24 so the workflow matches the package.json "engines" requirement and runs under Node 24 across the formatting, linting and tests jobs.
🤖 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/test.yml:
- Around line 25-29: CI is using Node.js 20 in the workflow's setup-node step;
update the node-version from 20 to 24 for all three jobs (formatting, linting,
tests) by changing the uses: actions/setup-node@v6 block where node-version: 20
to node-version: 24 so the workflow matches the package.json "engines"
requirement and runs under Node 24 across the formatting, linting and tests
jobs.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2d88a1a5-d335-4717-a40e-428227547424
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
.github/workflows/test.ymlpackage.jsonpnpm-workspace.yaml
There was a problem hiding this comment.
Note
Incremental review of 1ab62b9 and 6ccae46. Both follow-ups look clean: dropping the duplicate version: input lets Corepack consume the pinned packageManager field directly, and the Node 24 bump aligns CI with engines.node. The lockfile/overrides concern from my previous review is still outstanding (no related changes in these commits), so re-flagging it once here rather than as a new inline comment.
TL;DR — Two follow-up commits address the action-setup pinning feedback and align CI Node.js with engines.node: 24. No new issues introduced; the previously raised pnpm.overrides vs lockfile mismatch in package.json:93-98 remains the only outstanding concern.
Key changes since last review
- Drop redundant
version:input frompnpm/action-setup— three jobs updated; Corepack now resolves pnpm strictly frompackageManager. - Bump CI Node.js from 20 to 24 — matches
engines.nodeand unblocks pnpm v11 runtime requirements.
Summary ｜ 1 file (incremental) ｜ 2 new commits ｜ base: main ← upgrade/pnpm-11
Claude Opus ｜ 𝕏
Vercel auto-selects pnpm@9.x for older projects based on creation date, and pnpm 9 chokes on the pnpm@10+ `allowBuilds` config in pnpm-workspace.yaml. Override Vercel's install command so it enables Corepack first, which then picks up the pnpm version pinned via the `packageManager` field.
There was a problem hiding this comment.
Note
Worth verifying a Vercel preview deploy before merging. Corepack signature-verification failures (cannot find matching keyid) are a known failure mode on build images shipping older Corepack — they reproduce anywhere Corepack runs, including Vercel. The pinned integrity hash in packageManager does not rescue you from missing registry signing keys for pnpm@11.x. If the build image's bundled Corepack predates the keys that signed pnpm@11.1.1, every deploy will fail. Sources: Vercel KB on Corepack errors, vercel/vercel#12930. Node 24 itself is GA on Vercel, so engines.node: 24 is honored.
Reviewed the following changes:
- Added
vercel.jsonwithcorepack enable && pnpm install --frozen-lockfileto pin Vercel deploys to the samepnpm@11.1.1Corepack resolves locally and in CI.
Claude Opus ｜ 𝕏
`corepack enable` alone wasn't enough — Vercel's auto-installed pnpm@9 binary still won PATH precedence, so the post-enable `pnpm install` continued running under pnpm 9 and choked on the pnpm@10+ `allowBuilds` config. Pin pnpm via npx so the correct version runs regardless of PATH order.
There was a problem hiding this comment.
Note
Incremental review of 5672603. Swapping Vercel's install command from corepack enable && pnpm install to npx -y pnpm@11.1.1 install removes the Corepack dependency on prod deploys, resolving the signing-keyid risk I flagged on 47ba86c. The pinned 11.1.1 keeps version resolution deterministic; npm's own registry integrity covers the tarball. The previously raised pnpm.overrides vs lockfile mismatch in package.json:93-98 is untouched by this commit and remains the only outstanding concern.
Reviewed the following changes:
- Replaced the Corepack-based Vercel
installCommandwithnpx -y pnpm@11.1.1 install --frozen-lockfile, bypassing Corepack on deploy.
Claude Opus ｜ 𝕏
Install succeeded via npx pnpm 11.1.1 but Vercel then falls back to its bundled pnpm 9 for `pnpm run build`, which trips on the pnpm-workspace.yaml `allowBuilds` config. Force the build command through the same pinned pnpm 11.
There was a problem hiding this comment.
Note
Incremental review of 4798c4c. Adding buildCommand: npx -y pnpm@11.1.1 run build extends the same pinning strategy from install to build, so Vercel runs both phases under pnpm 11.1.1 instead of falling back to its auto-detected bundled pnpm (historically v9) for the build step. npx tarball caching means the second invocation reuses the pnpm install from the first call, so there's no meaningful overhead. The previously raised pnpm.overrides vs lockfile mismatch in package.json:93-98 is untouched by this commit and remains the only outstanding concern.
Reviewed the following changes:
- Pinned Vercel's
buildCommandtonpx -y pnpm@11.1.1 run build, matching the install command and removing the last path where Vercel could pick a non-pinned pnpm version.
Claude Opus ｜ 𝕏
1 participant
Summary
pnpm/action-setupversion in theTestingworkflow from9to1111.1.1via thepackageManagerfield inpackage.json(Corepack-compatible)pnpm-lock.yamlwith pnpm 11esbuild,sharp, andunrs-resolvervia a newpnpm-workspace.yaml, since pnpm 11 no longer runs postinstall scripts by defaultTest plan
pnpm install --frozen-lockfilesucceeds with pnpm 11pnpm run test:formatpassespnpm run lintpasses (no new errors)pnpm run testpasses (97/97 tests)pnpm run buildsucceeds end-to-endSummary by cubic
Upgrade project to
pnpmv11 with a pinnedpnpm@11.1.1. CI uses Node 24, and Vercel runs install and build with the pinnedpnpmto avoidpnpm@9.Dependencies
pnpm@11.1.1viapackageManagerinpackage.json;pnpm/action-setup@v5reads it (noversioninput).pnpm11.pnpm-workspace.yamlto allow builds foresbuild,sharp, andunrs-resolver.installCommandandbuildCommandtonpx -y pnpm@11.1.1 ...to force the pinnedpnpm.Migration
pnpm install --frozen-lockfile.Written for commit 3447f78. Summary will update on new commits. Review in cubic
Summary by CodeRabbit