Switch from yarn@1.22.22 to pnpm@11.0.8#949
Conversation
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
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:
📝 WalkthroughWalkthroughMigrate CI and project configuration from Yarn to pnpm and upgrade Node.js targets to 22.x; update package scripts, add a pnpm workspace config, and adjust CONTRIBUTING/README instructions. ChangesPackage Manager and Node.js Migration
Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant PnpmSetup as pnpm/action-setup@v6
participant SetupNode as actions/setup-node@v4
participant Runner
GitHubActions->>PnpmSetup: install pnpm (version from package.json)
GitHubActions->>SetupNode: configure Node 22.x + cache: pnpm
Runner->>Runner: pnpm install --ignore-scripts
Runner->>Runner: pnpm run lint / pnpm run test -- --coverage / pnpm run build / pnpm run ts:check
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 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)
Comment |
| strategy: | ||
| matrix: | ||
| node-version: [18.x] | ||
| node-version: [22.x] |
There was a problem hiding this comment.
Node.js 18 and 20 are EOL
There was a problem hiding this comment.
Pull request overview
Switches the project’s development package manager from Yarn Classic to pnpm, updating docs, scripts, CI, and pnpm workspace/security configuration.
Changes:
- Replaces Yarn commands with pnpm commands in scripts, docs, and GitHub Actions.
- Adds pnpm workspace configuration and pnpm lockfile.
- Pins
@types/nodeand updates CI to Node 22 with pnpm caching/Corepack.
Reviewed changes
Copilot reviewed 6 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| README.md | Updates install example from Yarn to pnpm. |
| CONTRIBUTING.md | Updates contributor setup, test, and release commands to pnpm. |
| package.json | Converts scripts to pnpm and pins pnpm/@types/node metadata. |
| pnpm-workspace.yaml | Adds pnpm workspace and security-related settings. |
| pnpm-lock.yaml | Adds pnpm dependency lockfile. |
| yarn.lock | Removes legacy Yarn lockfile. |
| .github/workflows/webpack.yaml | Updates PR CI workflow to Node 22 and pnpm. |
| .github/workflows/coveralls.yaml | Updates coverage workflow to Node 22 and pnpm. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 @.github/workflows/coveralls.yaml:
- Line 18: The CI job step using the pnpm/action-setup action (the step that
currently references "pnpm/action-setup@v6") should explicitly pin the pnpm
version via the action input to avoid the resolution bug; update that workflow
step to include a with: version: 11.0.8 (matching devEngines.packageManager) so
the action always installs pnpm 11.0.8 instead of relying on the action's
bootstrap resolution.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2015d31c-949c-4022-9627-680b0483090c
📒 Files selected for processing (4)
.github/workflows/coveralls.yaml.github/workflows/webpack.yamlREADME.mdpnpm-workspace.yaml
🚧 Files skipped from review as they are similar to previous changes (3)
- .github/workflows/webpack.yaml
- README.md
- pnpm-workspace.yaml
karlhorky
force-pushed
the
switch-from-yarn-v1-to-pnpm-v11
branch
from
249ea2b to
78b508b
Compare
| "name": "yarn", | ||
| "version": "1.22.22+sha512.a6b2f7906b721bba3d67d4aff083df04dad64c399707841b7acf00f6b133b7ac24255f2652fa22ae3534329dc6180534e98d17432037ff6fd140556e2bb3137e" | ||
| "name": "pnpm", | ||
| "version": "11.0.8+sha512.4c4097e1dd2d42372c4e7fa5a791ff28fc75a484c7ac192e64b1df0fdef17594ba982f9b4fed9adfb3c757846f565b799b2763fb3733d1de1bcb82cf46684912" |
There was a problem hiding this comment.
I'm still not succeeding in pnpm install. I'm getting the following error:
[ERROR] This project is configured to use 11.0.8+sha512.4c4097e1dd2d42372c4e7fa5a791ff28fc75a484c7ac192e64b1df0fdef17594ba982f9b4fed9adfb3c757846f565b799b2763fb3733d1de1bcb82cf46684912 of pnpm. Your current pnpm is v11.1.2
If you want to bypass this version check, you can set the "pmOnFail" configuration to "warn" or "ignore" (e.g. via --pm-on-fail=ignore). If using "devEngines.packageManager", you can set its "onFail" to "warn" or "ignore"
It seems to me that contrary to what pnpm docs say the download is not actually the default, because it works when I do:
pnpm install --pm-on-fail=downloadSimilarly when I explicitly set pmOnFail: download in the config file.
There was a problem hiding this comment.
Additionally, when I run with this download option enabled, I get the pnpm-lock.yaml file updated, because the pnpm 11.0.8 gets added to it as a dependency.
There was a problem hiding this comment.
oh, interesting. I wonder why the default 'download' behavior is not being used here. maybe this is a pnpm bug
if you give me the following details, I'll open a pnpm issue:
- what is the output of
pnpm config get pmOnFail? (*without* the config setting present inpnpm-workspace.yaml) - are there any relevant environment variables set? eg.
pnpm_config_pm_on_failorCOREPACK_* - How was pnpm 11.1.2 installed or invoked? eg. npm global install, standalone installer, Corepack, Volta, mise, Homebrew. even if not installed through Corepack, what are the outputs of
corepack --version,command -v pnpmandls -al "$(command -v pnpm)"? - which Node.js version and OS are you using? if OS is Linux, what distro / version?
once I open the issue, I can also configure pmOnFail: download in pnpm-workspace.yaml and mark it as a workaround while the pnpm bug is fixed, with a link to the issue
There was a problem hiding this comment.
what is the output of
pnpm config get pmOnFail?
Well, the output is the same error:
[ERROR] This project is configured to use 11.0.8+sha512.4c4097e1dd2d42372c4e7fa5a791ff28fc75a484c7ac192e64b1df0fdef17594ba982f9b4fed9adfb3c757846f565b799b2763fb3733d1de1bcb82cf46684912 of pnpm. Your current pnpm is v11.1.2
If you want to bypass this version check, you can set the "pmOnFail" configuration to "warn" or "ignore" (e.g. via --pm-on-fail=ignore). If using "devEngines.packageManager", you can set its "onFail" to "warn" or "ignore"
Even calling pnpm help gives me this same error.
are there any relevant environment variables set? eg.
pnpm_config_pm_on_failorCOREPACK_*
No.
How was pnpm 11.1.2 installed or invoked? eg. npm global install, standalone installer, Corepack, Volta, mise, Homebrew. even if not installed through Corepack, what are the outputs of
corepack --version,command -v pnpmandls -al "$(command -v pnpm)"?
Using brew install pnpm
which Node.js version and OS are you using?
- Node 22.22.3
- MacOS 26.3
I also tried whether the Fish shell might be the culprit, but no, same error with Bash.
There was a problem hiding this comment.
thanks!
2 things still open:
- try running the
pnpm config get pmOnFailin a different directory (or temporarily removedevEngines.packageManagerfrompackage.json)
and this part of number 3:
even if not installed through Corepack, what are the outputs of
corepack --version,command -v pnpmandls -al "$(command -v pnpm)"?
There was a problem hiding this comment.
If I run it one some random directory I get as result:
$ pnpm config get pmOnFail
undefined
Same, when I remove the devEngines.packageManager config.
$ corepack --version
0.34.6
$ command -v pnpm
/opt/homebrew/bin/pnpm
$ ls -al "$(command -v pnpm)"
lrwxr-xr-x 1 nene admin 30 May 14 22:26 /opt/homebrew/bin/pnpm@ -> ../Cellar/pnpm/11.1.2/bin/pnpm
There was a problem hiding this comment.
| # Prevent package trust metadata from downgrading on updates | ||
| # https://pnpm.io/settings#trustpolicy | ||
| trustPolicy: no-downgrade | ||
| trustPolicyExclude: | ||
| - eslint-config-prettier@8.10.2 | ||
| - eslint-plugin-prettier@4.2.5 | ||
| - semver@5.7.2 || 6.3.1 | ||
| - undici-types@6.19.8 |
There was a problem hiding this comment.
I wonder about these specific packages. What's the deal with them?
When I remove these entries, the install works fine. But for some reason we want to allow these packages to be replaced with lower trust versions in the future. Why?
There was a problem hiding this comment.
I added comments (which I also add in my own projects) to be clear why these versions are there:
the short version: previous versions before these versions had provenance
There was a problem hiding this comment.
an alternative would be using trustPolicyIgnoreAfter:
There was a problem hiding this comment.
BTW, what is "provenance"? It's a terminology I haven't come across before.
There was a problem hiding this comment.
it's an npm security mechanism, to allow verifying how a package was built:
| # Prevent package trust metadata from downgrading on updates | ||
| # https://pnpm.io/settings#trustpolicy | ||
| trustPolicy: no-downgrade | ||
| trustPolicyExclude: | ||
| # first version with provenance: eslint-config-prettier@10.1.4 https://github.com/prettier/eslint-config-prettier/issues/339#issuecomment-3090250555 | ||
| - eslint-config-prettier@8.10.2 | ||
| # first version with provenance: eslint-plugin-prettier@5.3.1 https://github.com/prettier/eslint-plugin-prettier/pull/757 | ||
| - eslint-plugin-prettier@4.2.5 | ||
| # first version with provenance: semver@7.5.1 https://github.com/npm/node-semver/issues/838#issuecomment-3698312268 | ||
| - semver@5.7.2 || 6.3.1 | ||
| # first version with provenance: undici-types@6.13.0 https://github.com/nodejs/undici/issues/4666 | ||
| - undici-types@6.19.8 |
There was a problem hiding this comment.
@nene an alternative for all of these packages (since they're all older than 60 days) is to ignore the trust policy downgrade (provenance disappearing on new versions) using trustPolicyIgnoreAfter
I'm using this on some of our projects:
| # Prevent package trust metadata from downgrading on updates | |
| # https://pnpm.io/settings#trustpolicy | |
| trustPolicy: no-downgrade | |
| trustPolicyExclude: | |
| # first version with provenance: eslint-config-prettier@10.1.4 https://github.com/prettier/eslint-config-prettier/issues/339#issuecomment-3090250555 | |
| - eslint-config-prettier@8.10.2 | |
| # first version with provenance: eslint-plugin-prettier@5.3.1 https://github.com/prettier/eslint-plugin-prettier/pull/757 | |
| - eslint-plugin-prettier@4.2.5 | |
| # first version with provenance: semver@7.5.1 https://github.com/npm/node-semver/issues/838#issuecomment-3698312268 | |
| - semver@5.7.2 || 6.3.1 | |
| # first version with provenance: undici-types@6.13.0 https://github.com/nodejs/undici/issues/4666 | |
| - undici-types@6.19.8 | |
| # Prevent trust level decreases with packages newer than 60 days | |
| # to mitigate supply chain risks | |
| # https://pnpm.io/settings#trustpolicy | |
| trustPolicy: no-downgrade | |
| trustPolicyIgnoreAfter: 86400 |
There was a problem hiding this comment.
I don't really understand this.
If we're currently using eslint-config-prettier@8.10.2 and that doesn't have provenance, how would it be possible to downgrade the provenance of this package? Is there some way of having negative provenance? And why would we want that? I'm not sure I really understand this provenance thing at all.
There was a problem hiding this comment.
pnpm's trustPolicy is time-based, not semver-based
as soon as a version with provenance is published (in this case eslint-config-prettier@10.1.4), then any future versions that are published (in this case eslint-config-prettier@8.10.2) are marked as a trust downgrade
it does make sense, if you think through a scenario where:
- attacker gets publish access to popular library, which has provenance on latest major
- attacker intentionally publishes older version (also with high download count), on a major version which has never had provenance
- to a casual observer, this new version may not appear dangerous
- pnpm
trustPolicyerrors about it
some community members find this counterintuitive (as did I when I first heard it). there's more discussion over in the issue I linked on the "provenance disappearing on new versions" link above:
There was a problem hiding this comment.
trustPolicyIgnoreAfter works around it by ignoring such violations of new versions after a certain period of time. I set it to 60 days in the code suggestion above, which is probably plenty of time for the static analysis security scanners and the community to find real malicious versions and for those versions to be removed from npm
Switch from yarn@1.22.22 to pnpm@11.0.8, as per #945 (comment).
This also pins
@types/node@22.9.0, matching the version previously resolved throughyarn.lock. Without the pin, pnpm resolves@types/node@25.6.0, which TypeScript 4.9 cannot check. The observed diagnostics:error TS1165: A computed property name in an ambient context must refer to an expression whose type is a literal type or a 'unique symbol' typeerror TS2339: Property 'dispose' does not exist on type 'SymbolConstructor'error TS2726: Cannot find lib definition for 'esnext.disposable'Install pnpm via the methods on the installation page:
TODO:
yarn.lockpnpm-lock.yamldevEngines.packageManagertopnpm@11.0.8@types/node@22.9.0verifyDepsBeforeRun: errorpackages: ['.']minimumReleaseAge: 10080minimumReleaseAgeStrict: trueminimumReleaseAgeIgnoreMissingTime: falsetrustPolicy: no-downgradeeslint-config-prettier@8.10.2eslint-plugin-prettier@4.2.5semver@5.7.2 || 6.3.1undici-types@6.19.8blockExoticSubdeps: trueSummary by CodeRabbit
Chores
Documentation