chore: upgrade pnpm to v11.25.0 - #3932
Conversation
Pin packageManager to the latest v11 release. Workspace config was already on the v11 shape (pnpm-workspace.yaml, allowBuilds), so the lockfile did not need a rewrite. Update Cloud agent notes to activate the pin via Corepack. Co-authored-by: Cody Olsen <stipsan@users.noreply.github.com>
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
There was a problem hiding this comment.
Pull request overview
This PR pins the monorepo to pnpm 11.25.0 via packageManager, and updates contributor/CI notes to reflect pnpm 11’s Node compatibility and Corepack-based activation.
Changes:
- Bumped the root
packageManagertopnpm@11.25.0. - Updated agent notes to use Corepack to activate the repo-pinned pnpm version after switching to the nvm Node.
- Added CI workflow commentary noting pnpm 11’s Node.js 22+ requirement (matrix remains on LTS lines).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| package.json | Pins the repo’s package manager to pnpm 11.25.0 via Corepack. |
| AGENTS.md | Updates local setup guidance to use Corepack for pnpm 11 activation. |
| .github/workflows/ci.yml | Documents pnpm 11’s Node version requirement alongside the existing LTS matrix. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| ``` | ||
|
|
||
| `nvm use` alone is not enough because `/exec-daemon` sits ahead of nvm's shims in `PATH`. This nvm node also bundles the correct `pnpm` (10.34.5), so prepending it fixes both `node` and `pnpm` in one step. `pnpm install` itself works on the default node; only building/running needs the newer node. `pnpm test:e2e` (Vitest browser project) needs Chromium: `pnpm playwright install chromium`. | ||
| `nvm use` alone is not enough because `/exec-daemon` sits ahead of nvm's shims in `PATH`. This nvm node also bundles a pnpm, but the repo pins pnpm 11 via `packageManager`. Activate that version with Corepack (`corepack enable && corepack prepare`) after prepending nvm. `pnpm install` itself works on the default node; only building/running needs the newer node. `pnpm test:e2e` (Vitest browser project) needs Chromium: `pnpm playwright install chromium`. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix prepared a fix for the issue found in the latest run.
- ✅ Fixed: Release provenance env var ignored
- Renamed NPM_CONFIG_PROVENANCE to PNPM_CONFIG_PROVENANCE in release.yml so pnpm 11's native publish still enables npm provenance for public releases.
Or push these changes by commenting:
@cursor push 9b8bee34f9
Preview (9b8bee34f9)
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -56,4 +56,4 @@
publish-script: pnpm release
env:
GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
- NPM_CONFIG_PROVENANCE: ${{ github.event.repository.visibility == 'public' && 'true' || 'false' }}
+ PNPM_CONFIG_PROVENANCE: ${{ github.event.repository.visibility == 'public' && 'true' || 'false' }}You can send follow-ups to the cloud agent here.
Reviewed by Cursor Bugbot for commit a53b8da. Configure here.
| "pkg-pr-new": "^0.0.87" | ||
| }, | ||
| "packageManager": "pnpm@10.34.5" | ||
| "packageManager": "pnpm@11.25.0" |
There was a problem hiding this comment.
Release provenance env var ignored
Medium Severity
Pinning packageManager to pnpm 11 switches changeset publish onto native pnpm publish, which no longer reads npm_config_* variables. NPM_CONFIG_PROVENANCE in the release workflow is therefore ignored, so public next-sanity releases can ship without npm provenance attestations.
Reviewed by Cursor Bugbot for commit a53b8da. Configure here.
pnpm 11 defaults strictDepBuilds to true, so an unapproved build script fails the install instead of warning. msw arrives transitively through @vitest/browser and nothing here uses it, so deny its build. CI never caught this because every workflow installs with --ignore-scripts; Vercel runs a plain pnpm install and its apps/mvp build failed. Co-authored-by: Cody Olsen <stipsan@users.noreply.github.com>
Every workflow used --ignore-scripts, which skips pnpm 11's check for unapproved dependency build scripts. That let a failing install reach Vercel with all GitHub checks green. Nothing here approves a build script, so a plain install runs no dependency builds; it only enforces the gate. Co-authored-by: Cody Olsen <stipsan@users.noreply.github.com>
Pin the repo to pnpm 11.25.0 (
latest-11).Library consumers are unaffected. CI and contributors pick up pnpm 11 through
packageManagerandpnpm/action-setup.What changed
packageManageris nowpnpm@11.25.0.allowBuildsdeniesmsw, which pnpm 11 requires an explicit decision on (see below).buildjob installs with scripts instead of--ignore-scripts, so an unapproved build script fails there rather than only on Vercel.corepack enable && corepack prepareafter prepending nvm Node.What did not change
pnpm-workspace.yamlwas already on the v11 shape (allowBuilds, nopackage.json#pnpm, no project.npmrc).pnpm-lock.yamldid not need a rewrite; it stays atlockfileVersion: 9.0, which is what pnpm 11 writes.pnpm-v10-to-v11codemod made no edits.The Vercel failure on the first push
The first commit passed all 13 GitHub checks and failed the
Vercel – next-sanitydeployment. pnpm 11 flipsstrictDepBuildstotrue, so a dependency with an unapproved build script now fails the install instead of warning:mswarrives transitively through@vitest/browserand no code here imports it, so its build is denied. Denying the build script does not disable msw: the browser tests still exercise it as a request interceptor.Every workflow installed with
--ignore-scripts, which skips this check entirely, and no CI job buildsapps/mvp. Vercel runs a plainpnpm installand builds that app, so it was the only place the failure could appear. Hence the CI change above.v11 defaults we are keeping
minimumReleaseAge(1 day) andblockExoticSubdeps. Canary Next andsanity: nextare pinned in the lockfile, and the supply-chain verification passes.pnpm publishis out of scope. Changesets still publish through npm, soNPM_CONFIG_PROVENANCEin release is unchanged.Verified locally on pnpm 11.25.0 / Node 22.22.2
pnpm install(with scripts, as Vercel runs it) succeeds; it fails without themswentry.pnpm --filter mvp buildandpnpm --filter static buildboth succeed. These are the two Vercel projects.pnpm lint,pnpm knip,pnpm test(171 unit tests plus fixture builds), andpnpm test:e2e(21 browser tests) all pass.