chore: harden pnpm installs#32
Conversation
WalkthroughThis PR consolidates pnpm configuration by moving settings from Changespnpm Configuration Consolidation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
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)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
package.json (1)
45-45: ⚡ Quick winBound
pnpm.overridesranges to prevent accidental major-version jumps.Unbounded floors (
>=...) inpnpm.overridescan silently pull future majors during lockfile refresh. Use bounded ranges (e.g.,>=1.15.2 <2) for patch/minor security updates only:
axios(line 45): Change>=1.15.2to>=1.15.2 <2follow-redirects(line 51): Change>=1.16.0to>=1.16.0 <2apisauce>axios(line 87): Change>=1.15.2to>=1.15.2 <2🤖 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 `@package.json` at line 45, The pnpm.overrides entries use unbounded floors like ">=1.15.2" which can allow accidental major-version upgrades; update the override values for the axios override key ("axios"), follow-redirects override key ("follow-redirects"), and the nested override for apisauce's axios ("apisauce>axios") to bounded ranges that prevent major jumps (e.g., change ">=1.15.2" to ">=1.15.2 <2" and ">=1.16.0" to ">=1.16.0 <2") so only patch/minor updates are allowed during lockfile refresh.
🤖 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.
Nitpick comments:
In `@package.json`:
- Line 45: The pnpm.overrides entries use unbounded floors like ">=1.15.2" which
can allow accidental major-version upgrades; update the override values for the
axios override key ("axios"), follow-redirects override key
("follow-redirects"), and the nested override for apisauce's axios
("apisauce>axios") to bounded ranges that prevent major jumps (e.g., change
">=1.15.2" to ">=1.15.2 <2" and ">=1.16.0" to ">=1.16.0 <2") so only patch/minor
updates are allowed during lockfile refresh.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4e986fff-b929-4cda-b153-3154e4e1863f
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
.github/actions/bootstrap/action.ymlpackage.jsonpnpm-workspace.yaml
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`:
- Around line 38-42: The packageManager field is pinned to [email protected] which
overrides the widened "engines.pnpm": ">=10.33.0" range; either remove the
packageManager entry so Corepack will respect the engines.pnpm range, or replace
it by adding a devEngines.packageManager with a range (e.g., "pnpm@>=10.33.0")
so the project allows pnpm 11+ while preserving Corepack behavior; update the
package.json by removing "packageManager": "[email protected]" or adding
"devEngines.packageManager" and ensure no conflicting packageManager remains,
referencing the packageManager, engines.pnpm, devEngines.packageManager, and
Corepack behavior when making the change.
🪄 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: 418d3178-0615-43a0-b16c-fccd6764313b
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
.npmrcpackage.jsonpnpm-workspace.yaml
💤 Files with no reviewable changes (1)
- .npmrc
🚧 Files skipped from review as they are similar to previous changes (1)
- pnpm-workspace.yaml
| "pnpm": ">=10.33.0", | ||
| "npm": "use-pnpm", | ||
| "yarn": "use-pnpm" | ||
| }, | ||
| "pnpm": { | ||
| "overrides": { | ||
| "ajv": "6.14.0", | ||
| "axios": ">=1.15.0", | ||
| "brace-expansion": ">=1.1.13", | ||
| "braces": ">=3.0.3", | ||
| "cross-spawn": ">=7.0.5", | ||
| "ejs": ">=3.1.10", | ||
| "flatted": ">=3.4.2", | ||
| "follow-redirects": ">=1.15.6", | ||
| "glob": ">=11.1.0", | ||
| "immutable": ">=5.1.5", | ||
| "js-yaml": ">=4.1.1", | ||
| "lodash.trim": "4.18.0", | ||
| "lodash.trimend": "4.18.0", | ||
| "micromatch": ">=4.0.8", | ||
| "minimatch": ">=3.1.4", | ||
| "picomatch": ">=2.3.2", | ||
| "semver": ">=7.5.2", | ||
| "undici": ">=7.24.0", | ||
| "word-wrap": ">=1.2.4", | ||
| "yaml": ">=2.8.3", | ||
| "ajv@<6.14.0": "6.14.0", | ||
| "axios@<0.30.0": ">=0.30.0", | ||
| "axios@<=0.30.2": ">=0.30.3", | ||
| "axios@>=0.8.1 <0.28.0": ">=0.28.0", | ||
| "brace-expansion@<1.1.13": ">=1.1.13", | ||
| "brace-expansion@>=1.0.0 <=1.1.11": ">=1.1.12", | ||
| "braces@<3.0.3": ">=3.0.3", | ||
| "cross-spawn@>=7.0.0 <7.0.5": ">=7.0.5", | ||
| "ejs@<3.1.10": ">=3.1.10", | ||
| "flatted@<3.4.0": ">=3.4.0", | ||
| "flatted@<=3.4.1": ">=3.4.2", | ||
| "follow-redirects@<1.15.4": ">=1.15.4", | ||
| "follow-redirects@<=1.15.5": ">=1.15.6", | ||
| "glob@>=11.0.0 <11.1.0": ">=11.1.0", | ||
| "immutable@>=5.0.0 <5.1.5": ">=5.1.5", | ||
| "js-yaml@>=4.0.0 <4.1.1": ">=4.1.1", | ||
| "micromatch@<4.0.8": ">=4.0.8", | ||
| "minimatch@<3.1.3": ">=3.1.3", | ||
| "minimatch@<3.1.4": ">=3.1.4", | ||
| "picomatch@<2.3.2": ">=2.3.2", | ||
| "semver@>=7.0.0 <7.5.2": ">=7.5.2", | ||
| "tmp@<=0.2.3": ">=0.2.4", | ||
| "undici@>=7.0.0 <7.18.2": ">=7.18.2", | ||
| "undici@>=7.0.0 <7.24.0": ">=7.24.0", | ||
| "word-wrap@<1.2.4": ">=1.2.4", | ||
| "yaml@>=1.0.0 <1.10.3": ">=1.10.3", | ||
| "yaml@>=2.0.0 <2.8.3": ">=2.8.3", | ||
| "axios@<1.15.0": ">=1.15.0", | ||
| "apisauce>axios": ">=1.15.0" | ||
| } | ||
| } | ||
| "packageManager": "[email protected]" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n package.json | sed -n '35,45p'Repository: OlympusDAO/bonds-subgraph
Length of output: 285
🌐 Web query:
Node.js Corepack packageManager field behavior exact version pin enforcement
💡 Result:
The Node.js Corepack packageManager field in package.json specifies the exact package manager (yarn, pnpm, or npm) and version to use for the project, in the format "name@version[+hash]", e.g., "[email protected]" or with an optional SHA hash for security like "[email protected]+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa" [1][2][3]. Corepack proxies (enabled via corepack enable) read the nearest package.json, download and run the pinned exact version if needed, ensuring reproducible installs across environments [4][5][1]. Version pinning is enforced strictly by default: Corepack aborts with an error (e.g., "UsageError: This project is configured to use npm because./package.json has a 'packageManager' field") if a mismatched package manager binary is invoked [6][7][8]. It runs the exact specified version (patch-level), not a range, downloading from the registry if absent from cache [4][9][10]. This strict enforcement is controlled by COREPACK_ENABLE_STRICT=1 (default). Set to 0 for "transparent" mode: matching PM uses the pinned version; mismatch falls back to system/global version without error [1][8][11][12]. Auto-pinning (Corepack adding/updating the field) is off by default (COREPACK_ENABLE_AUTO_PIN=0) but can be enabled [7][13][1]. Projects can override via .corepack.env [14][15]. npm support is partial (no shims by default, uses global npm) [4][5]. Use corepack use name@version to set/update the field [1][16]. As of 2026, behavior unchanged in recent Node docs [5][16].
Citations:
- 1: https://github.com/nodejs/corepack
- 2: https://stackoverflow.com/questions/71747609/how-to-specify-packagemanager-in-package-json
- 3: https://www.npmjs.com/package/corepack
- 4: https://r2.nodejs.org/dist/v22.4.0/docs/api/corepack.html
- 5: https://r2.nodejs.org/docs/v22.8.0/api/corepack.html
- 6: https://blog.hyperknot.com/p/corepacks-packagemanager-field
- 7: https://stackoverflow.com/questions/78795659/how-to-disable-auto-setting-of-packagemanager-when-corepack-is-enabled
- 8: Drop the corepack package manager strict check when invoked by another process nodejs/corepack#209
- 9: Corepack not using specified package manager version (in this example, pnpm) nodejs/corepack#659
- 10: https://corepack.org/how-does-corepack-automatically-manage-yarn-and-pnpm-versions/
- 11: https://deepwiki.com/nodejs/corepack/6.1-environment-variables
- 12: feat: add
COREPACK_ENABLE_STRICTenv variable nodejs/corepack#167 - 13:
COREPACK_ENABLE_AUTO_PINshould default to0nodejs/corepack#485 - 14: feat: add support for
.corepack.envnodejs/corepack#642 - 15: corepack use does not load COREPACK_NPM_REGISTRY from .corepack.env nodejs/corepack#741
- 16: https://r2.nodejs.org/docs/latest-iron/api/corepack.html
🌐 Web query:
pnpm 11 devEngines.packageManager support
💡 Result:
pnpm 11 fully supports devEngines.packageManager in package.json for specifying the required pnpm version, introduced in v11.0.0 [1][2]. This field allows semver ranges (unlike the legacy packageManager field), with the resolved version stored in pnpm-lock.yaml under packageManagerDependencies for reuse if it satisfies the range [3][1]. Example usage: json { "devEngines": { "packageManager": { "name": "pnpm", "version": ">=11.0.0", "onFail": "download" } } } onFail options: download (auto-download), error (default), warn, ignore [3][1]. It takes precedence over packageManager (with warning if both present) [3][4]. pnpm init now uses this field by default when init-package-manager is enabled [2]. Override onFail via pmOnFail setting [1]. Legacy packageManager derives onFail from configs like managePackageManagerVersions [3][2].
Citations:
- 1: https://pnpm.io/11.x/package_json
- 2: https://pnpm.io/blog/releases/11.0
- 3: feat: support
devEngines.packageManagerfor pnpm version management pnpm/pnpm#10932 - 4: Better migration path for devEngines.packageManager pnpm/pnpm#11301
packageManager pin negates the widened pnpm range.
"pnpm": ">=10.33.0" permits pnpm 11+, but "packageManager": "[email protected]" instructs Corepack to use exactly version 10.33.0 for this project. Corepack enforces this at patch-level precision by default, preventing pnpm 11 from being used even when the engines field allows it. This directly contradicts the PR objective to unpin pnpm from 10.33.0.
The compatible solutions are:
- Remove the
packageManagerfield entirely to let theengines.pnpmrange take effect. - For pnpm 11+, use
devEngines.packageManagerwith a range instead of the legacypackageManagerfield.
Suggested change (Option 1)
"engines": {
"node": ">=24",
"pnpm": ">=10.33.0",
"npm": "use-pnpm",
"yarn": "use-pnpm"
- },
- "packageManager": "[email protected]"
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "pnpm": ">=10.33.0", | |
| "npm": "use-pnpm", | |
| "yarn": "use-pnpm" | |
| }, | |
| "pnpm": { | |
| "overrides": { | |
| "ajv": "6.14.0", | |
| "axios": ">=1.15.0", | |
| "brace-expansion": ">=1.1.13", | |
| "braces": ">=3.0.3", | |
| "cross-spawn": ">=7.0.5", | |
| "ejs": ">=3.1.10", | |
| "flatted": ">=3.4.2", | |
| "follow-redirects": ">=1.15.6", | |
| "glob": ">=11.1.0", | |
| "immutable": ">=5.1.5", | |
| "js-yaml": ">=4.1.1", | |
| "lodash.trim": "4.18.0", | |
| "lodash.trimend": "4.18.0", | |
| "micromatch": ">=4.0.8", | |
| "minimatch": ">=3.1.4", | |
| "picomatch": ">=2.3.2", | |
| "semver": ">=7.5.2", | |
| "undici": ">=7.24.0", | |
| "word-wrap": ">=1.2.4", | |
| "yaml": ">=2.8.3", | |
| "ajv@<6.14.0": "6.14.0", | |
| "axios@<0.30.0": ">=0.30.0", | |
| "axios@<=0.30.2": ">=0.30.3", | |
| "axios@>=0.8.1 <0.28.0": ">=0.28.0", | |
| "brace-expansion@<1.1.13": ">=1.1.13", | |
| "brace-expansion@>=1.0.0 <=1.1.11": ">=1.1.12", | |
| "braces@<3.0.3": ">=3.0.3", | |
| "cross-spawn@>=7.0.0 <7.0.5": ">=7.0.5", | |
| "ejs@<3.1.10": ">=3.1.10", | |
| "flatted@<3.4.0": ">=3.4.0", | |
| "flatted@<=3.4.1": ">=3.4.2", | |
| "follow-redirects@<1.15.4": ">=1.15.4", | |
| "follow-redirects@<=1.15.5": ">=1.15.6", | |
| "glob@>=11.0.0 <11.1.0": ">=11.1.0", | |
| "immutable@>=5.0.0 <5.1.5": ">=5.1.5", | |
| "js-yaml@>=4.0.0 <4.1.1": ">=4.1.1", | |
| "micromatch@<4.0.8": ">=4.0.8", | |
| "minimatch@<3.1.3": ">=3.1.3", | |
| "minimatch@<3.1.4": ">=3.1.4", | |
| "picomatch@<2.3.2": ">=2.3.2", | |
| "semver@>=7.0.0 <7.5.2": ">=7.5.2", | |
| "tmp@<=0.2.3": ">=0.2.4", | |
| "undici@>=7.0.0 <7.18.2": ">=7.18.2", | |
| "undici@>=7.0.0 <7.24.0": ">=7.24.0", | |
| "word-wrap@<1.2.4": ">=1.2.4", | |
| "yaml@>=1.0.0 <1.10.3": ">=1.10.3", | |
| "yaml@>=2.0.0 <2.8.3": ">=2.8.3", | |
| "axios@<1.15.0": ">=1.15.0", | |
| "apisauce>axios": ">=1.15.0" | |
| } | |
| } | |
| "packageManager": "[email protected]" | |
| "pnpm": ">=10.33.0", | |
| "npm": "use-pnpm", | |
| "yarn": "use-pnpm" | |
| } |
🤖 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 `@package.json` around lines 38 - 42, The packageManager field is pinned to
[email protected] which overrides the widened "engines.pnpm": ">=10.33.0" range;
either remove the packageManager entry so Corepack will respect the engines.pnpm
range, or replace it by adding a devEngines.packageManager with a range (e.g.,
"pnpm@>=10.33.0") so the project allows pnpm 11+ while preserving Corepack
behavior; update the package.json by removing "packageManager": "[email protected]"
or adding "devEngines.packageManager" and ensure no conflicting packageManager
remains, referencing the packageManager, engines.pnpm,
devEngines.packageManager, and Corepack behavior when making the change.
2 participants
Summary
engines.pnpmpackageManagerpin so pnpm 11 is not forced back to 10.33.0Validation
package.jsonas JSONminimumReleaseAgefrompnpm-workspace.yamlSummary by CodeRabbit