chore: upgrade to pnpm v11#496
Conversation
Bump packageManager from pnpm@10.34.1 to pnpm@11.5.1. Lockfile format (v9.0) is unchanged and CI's pnpm/action-setup@v6 reads the version from packageManager automatically. Note: pnpm 11 enables a default minimumReleaseAge of 24h as a supply-chain protection. Two recently-bumped deps (@iconify-json/simple-icons, @iconify/collections) were published within that window, so CI will pass once they clear 24h. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe PR updates workspace tooling: package.json's packageManager was bumped from pnpm@10.34.1 to pnpm@11.5.1, and pnpm-workspace.yaml was changed to enable shamefullyHoist, disable strict peer dependency enforcement, set ignoreWorkspaceRootCheck, and replace the previous onlyBuiltDependencies list with an allowBuilds map that disables Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 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.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@package.json`:
- Line 3: Verify the pinned packageManager entry ("packageManager":
"pnpm@11.5.1") is an actual published pnpm tag/version and update it to the
exact published version string if it differs (e.g., pnpm@11.5.x or the correct
tag), then review CI/workspace pnpm settings for minimumReleaseAge and
minimumReleaseAgeStrict (or equivalent flags) to ensure strict mode isn't
enabled or adjust the pinned version/CI to tolerate new releases; specifically,
check repository CI config and pnpmrc/workspace config for
minimumReleaseAge/minimumReleaseAgeStrict and either disable strict enforcement
or choose a released pnpm version that meets your CI requirements.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
pnpm v11 makes .npmrc auth/registry-only and replaces onlyBuiltDependencies with the allowBuilds map. Applied the official pnpm-v10-to-v11 codemod, plus an explicit '@parcel/watcher': false entry — without it pnpm v11's runDepsStatusCheck exits 1 on the ignored-builds warning under strictDepBuilds and breaks nested `pnpm run` chains like `npm run test`. @parcel/watcher was never in the original onlyBuiltDependencies, so this preserves the existing pnpm v10 behaviour (its postinstall was already being silently skipped; modern versions ship prebuilt binaries via optional deps). Verified locally on pnpm v11.5.1: install, dev:prepare, lint, build, typecheck, and test all exit 0 with clean output. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
commit: |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
pnpm-workspace.yaml (1)
5-5: 💤 Low value
ignoreWorkspaceRootCheck: truerelaxes workspace validation.This setting allows pnpm commands to run without the usual workspace root check. While less critical than the hoisting and peer dependency settings, it removes a safeguard that helps ensure commands are run from the correct location in a workspace.
Recommendation: Confirm this setting is necessary. If the workspace structure is straightforward, consider removing it to preserve validation checks.
🤖 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 `@pnpm-workspace.yaml` at line 5, The pnpm workspace config sets ignoreWorkspaceRootCheck: true which disables pnpm's workspace root validation; if this relaxation is not required, remove the ignoreWorkspaceRootCheck entry (or set it to false) in pnpm-workspace.yaml to restore the safeguard. Locate the ignoreWorkspaceRootCheck key in pnpm-workspace.yaml and delete the line or change its value so pnpm enforces the workspace root check again.
🤖 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.
Inline comments:
In `@pnpm-workspace.yaml`:
- Line 4: Update the workspace config to enable peer dependency validation by
changing the strictPeerDependencies setting to true (replace the current
strictPeerDependencies: false), then resolve any existing conflicts rather than
disabling the check—use the peerDependencyRules section to add scoped exceptions
or overrides for specific package pairs that are known-acceptable; locate the
strictPeerDependencies key in the pnpm-workspace.yaml and add or modify a
peerDependencyRules block to explicitly whitelist or pin exceptions where
necessary.
- Line 3: Remove the global hoisting setting "shamefullyHoist: true" from
pnpm-workspace.yaml to restore pnpm's strict dependency isolation; if a specific
tool requires hoisting, replace the blanket setting with a targeted
publicHoistPattern entry and add a comment explaining which tool needs it and
why (or keep a short justification in project docs) so we avoid phantom
dependencies and preserve reproducible installs.
---
Nitpick comments:
In `@pnpm-workspace.yaml`:
- Line 5: The pnpm workspace config sets ignoreWorkspaceRootCheck: true which
disables pnpm's workspace root validation; if this relaxation is not required,
remove the ignoreWorkspaceRootCheck entry (or set it to false) in
pnpm-workspace.yaml to restore the safeguard. Locate the
ignoreWorkspaceRootCheck key in pnpm-workspace.yaml and delete the line or
change its value so pnpm enforces the workspace root check again.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d1dd250c-18ba-4283-b1f1-73008918b5de
📒 Files selected for processing (2)
.npmrcpnpm-workspace.yaml
💤 Files with no reviewable changes (1)
- .npmrc
| - esbuild | ||
| - sharp | ||
| - unrs-resolver | ||
| shamefullyHoist: true |
There was a problem hiding this comment.
shamefullyHoist: true degrades dependency isolation and enables phantom dependencies.
Setting shamefullyHoist: true hoists all dependencies to the root node_modules directory, which means "application code will have access to phantom dependencies." This defeats one of pnpm's core security features: strict dependency isolation. Phantom dependencies are packages not explicitly declared in package.json that become accessible due to hoisting, leading to:
- Hidden dependencies that can break when transitive deps change versions.
- Security risks from unmonitored packages.
- Reproducibility issues across environments.
This setting is "useful when dealing with some flawed pluggable tools that don't resolve dependencies properly," but it should be a last resort. If specific tools require hoisting, prefer targeted publicHoistPattern instead of blanket hoisting.
Recommendation: Remove shamefullyHoist: true unless you have confirmed that specific tooling absolutely requires it. If needed, document which tool necessitates this workaround and consider migrating to tooling that respects pnpm's dependency model.
🤖 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 `@pnpm-workspace.yaml` at line 3, Remove the global hoisting setting
"shamefullyHoist: true" from pnpm-workspace.yaml to restore pnpm's strict
dependency isolation; if a specific tool requires hoisting, replace the blanket
setting with a targeted publicHoistPattern entry and add a comment explaining
which tool needs it and why (or keep a short justification in project docs) so
we avoid phantom dependencies and preserve reproducible installs.
| - sharp | ||
| - unrs-resolver | ||
| shamefullyHoist: true | ||
| strictPeerDependencies: false |
There was a problem hiding this comment.
strictPeerDependencies: false bypasses peer dependency contract validation.
Setting strictPeerDependencies to false disables validation of peer dependencies, which is "an invalid state that can cause build failures or incompatible dependency versions." Rush Stack documentation "strongly recommend[s] to set strictPeerDependencies=true" for production codebases.
By disabling this check, you allow:
- Runtime errors from incompatible peer dependency versions.
- Silent failures that won't surface until production.
- CI/CD risks where automated PRs from Renovate/Dependabot may introduce breaking peer dependency mismatches without detection.
Recommendation: Enable strictPeerDependencies: true and resolve any peer dependency conflicts using peerDependencyRules to selectively suppress known acceptable violations, rather than disabling all validation.
🤖 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 `@pnpm-workspace.yaml` at line 4, Update the workspace config to enable peer
dependency validation by changing the strictPeerDependencies setting to true
(replace the current strictPeerDependencies: false), then resolve any existing
conflicts rather than disabling the check—use the peerDependencyRules section to
add scoped exceptions or overrides for specific package pairs that are
known-acceptable; locate the strictPeerDependencies key in the
pnpm-workspace.yaml and add or modify a peerDependencyRules block to explicitly
whitelist or pin exceptions where necessary.
Summary
Upgrades the package manager from
pnpm@10.34.1topnpm@11.5.1.packageManagerfield inpackage.jsonchanges.v9.0(unchanged between pnpm 10 and 11), sopnpm-lock.yamlis untouched.pnpm/action-setup@v6without a pinned version, so it reads the new version frompackageManagerautomatically — no workflow changes needed.minimumReleaseAgeby defaultpnpm 11 now blocks dependencies published less than 24h ago as a supply-chain protection. Two deps from the most recent Renovate bump are still inside that window:
@iconify-json/simple-icons@1.2.85@iconify/collections@1.0.692This makes the CI install fail until those packages clear the 24h window (~
04:40 UTC). Once that passes, CI should go green with no further changes — hence merging tomorrow.Going forward, future Renovate PRs will wait 24h before their deps are installable. If that friction proves annoying, we can later tune
minimumReleaseAge/minimumReleaseAgeExcludeinpnpm-workspace.yaml.🤖 Generated with Claude Code