Update pnpm to v11.12.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
pnpm (source)	11.11.0 → 11.12.0

---

Release Notes

pnpm/pnpm (pnpm)

v11.12.0

Compare Source

Minor Changes

• a897ef7: Custom fetchers exported from a pnpmfile can now delegate by returning a { delegate: <resolution> } envelope: pnpm rewrites the package's resolution to the delegated shape and runs the built-in fetcher on it. This is the portable delegation form that also works in pacquet, where cafs and fetchers cannot be passed to the hook. Related to pnpm/pnpm#11685.

Patch Changes

• 2b02764: The changed-packages filter (--filter "...[<since>]") no longer allows an option-like <since> value (such as --output=<path>) to be interpreted as a git option — git now rejects it as a bad revision. The repository root is also resolved to the nearest .git entry, so the filter works in a git worktree checked out inside another repository's tree.

• 43711ce: pnpm outdated no longer checks the registry for dependencies that are resolved from local link:, file:, or workspace: references in the lockfile #​12827.

• 3c6718b: Fixed a deadlock in peer dependency resolution: pnpm install hung forever when a peer dependency cycle spanned a project's own dependencies and auto-installed peer providers, for example when installing electron-builder@26.15.3 #​12921.

• 252f15e: Fixed peer dependency auto-install picking a version the peer range rejects. In a workspace with several projects, a package declaring a peer dependency with a semver range (for example ^1.0.0) could get the highest version found anywhere in the workspace (for example a 2.0.0 resolved for another project) instead of a version that satisfies the range. Peers are now deduplicated onto the highest preferred version that satisfies the declared range, and when none does, the range is resolved from the registry.

  Also fixed re-resolving with an existing lockfile hoisting a different peer version than a fresh install of the same manifest: root dependencies reused from the lockfile were invisible to peer hoisting, so a peer that a root dependency provides could be bound to another version.

• a38adda: pnpm self-update <version> now installs the requested pnpm version when it matches the currently running version but is missing from the global self-update directory.

• 6a85968: pnpm stage list now stops paginating after a fail-safe cap of 1000 pages, so a misbehaving registry cannot keep the command looping forever.

• eee7c9a: verify-deps-before-run no longer spawns a pnpm install when pnpm is executed in a directory that has no package.json. A mistyped command run outside a project (for example pnpm witch 10 login) used to crash with a confusing error from the spawned install; now it fails with the regular "no package.json found" error.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[shunichironomura]

The CI failure is caused by an upstream pnpm self-update bug, not by this repository or its lockfile.

pnpm/action-setup@v6.0.9 bootstraps pnpm 11.7.0 and then attempts to self-update to the packageManager version, pnpm 11.12.0. That update crashes before project dependencies are installed:

Cannot use 'in' operator to search for 'integrity' in undefined

This is the peer-qualified global lockfile issue tracked upstream:

• self-update crashes with Cannot use 'in' operator to search for 'integrity' in undefined due to peer dependencies pnpm/pnpm#12959
• fix(self-updater): fix missing resolution for peer dependencies in env lockfile pnpm/pnpm#12960
• Cannot use 'in' operator to search for 'integrity' in undefined pnpm/action-setup#276

It affects every frontend job and Rust's check-types job because those jobs run pnpm/action-setup; unrelated CI jobs pass. I also verified locally with pnpm 11.12.0 that pnpm install --frozen-lockfile, pnpm run vp:check, pnpm run check, and pnpm run build all succeed.

The safest immediate resolution is to close this PR and remain on pnpm 11.11.0 until the upstream fix is released. If 11.12.0 is required, CI can instead bypass pnpm/action-setup and install it directly with npm install --global pnpm@11.12.0 after actions/setup-node.