New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PNPM mysteriously installs unrelated packages #5132
Comments
To clarify, these extraneous packages are not linked into the project's node_modules/.modules.yaml hoistPattern:
- '*'
hoistedDependencies:
/@babel/helper-validator-identifier/7.18.6:
'@babel/helper-validator-identifier': private
/@babel/types/7.18.9:
'@babel/types': public
/to-fast-properties/2.0.0:
to-fast-properties: private
included:
dependencies: true
devDependencies: true
optionalDependencies: true
injectedDeps: {}
layoutVersion: 5
nodeLinker: isolated
packageManager: pnpm@6.33.0
pendingBuilds: []
prunedAt: Mon, 01 Aug 2022 01:06:56 GMT
publicHoistPattern:
- '*types*'
- '*eslint*'
- '@prettier/plugin-*'
- '*prettier-plugin-*'
registries:
default: https://registry.npmjs.org/
skipped: []
storeDir: C:\Users\Owner\.pnpm-store\v3
virtualStoreDir: C:\test\node_modules\.pnpm I encountered this while investigating an unwanted upgrade. The appearance of these packages in pnpm-lock.yaml seems to be new. When installing a lockfile that does not have these dependencies (probably from an older PNPM?) that difference seems to be triggering an unwanted upgrade. (?) |
@zkochan is it true that...
If so, this is counterintuitive. Can we disable this magic somehow? Or even better, is there a way for us to store the fixup rules explicitly in a Git-tracked file that our developers can easily be aware of and inspect? |
Looks like the implementation is here: pnpm/packages/core/src/install/index.ts Line 59 in 4fa1091
pnpm/packages/core/src/install/index.ts Lines 562 to 569 in 4fa1091
|
After a bunch of experiments, I determined that this behavior was introduced in PNPM version Empirical results:
In the past, deleting pnpm-lock.yaml was sufficient to fully reset PNPM's version selections. It seems that now we must delete both pnpm-lock.yaml and node_modules/.pnpm/lock.yaml, otherwise some state is persisted. For the 7.x series, the problem is introduced in version Summary👉 The most recent releases unaffected by this problem are In order to eliminate the extra dependencies, you must do all of the following:
|
I discussed this with Zoltan, who responded quickly and was very helpful. 🙏 The plan is to implement a setting to optionally disable the It's also worth considering whether these fixups should be applied earlier, since |
pnpm version: 6.33.0
Code to reproduce the issue:
@babel/parser
package:Expected behavior:
Only
@babel/parser
should get installed, because its package.json file specifies no dependencies:@babel/parser/package.json
Actual behavior:
For some reason
@babel/types
and (its dependencies)to-fast-properties
and@babel/helper-validator-identifier
are also getting installed:pnpm-lock.yaml
This doesn't repro with NPM 8.11.0 or Yarn 1.22.19 -- those package managers install
@babel/parser
only.Additional information:
node -v
prints: 14.19.3The text was updated successfully, but these errors were encountered: