fix: give priority to packages installed in the root, when deduping #6054
Conversation
| '@types/node': 18.11.18 | ||
| '@types/node': 14.18.36 |
There was a problem hiding this comment.
Assuming the move from 18.11.18 to 14.18.36 was one of the motivating reasons for this PR?
There was a problem hiding this comment.
This one might be fixed by this PR.
| "pnpm": patch | ||
| --- | ||
|
|
||
| When resolving dependencies, prefer versions that are already used in the root of the project. This is important to minimize the number of packages that will be nested during hoisting [#6054](https://github.com/pnpm/pnpm/pull/6054). |
There was a problem hiding this comment.
This change prefers selectors used by the any importer (or internal package), right? The phrasing "in the root of the project" might imply this only affects the root package.json?
There was a problem hiding this comment.
This change prefers selectors used by the any importer
yes
| @@ -10530,7 +10501,7 @@ packages: | |||
| object-assign: 4.1.1 | |||
| vary: 1.1.2 | |||
|
|
|||
| /cosmiconfig-typescript-loader@4.3.0(@types/node@18.11.18)(cosmiconfig@8.0.0)(ts-node@10.9.1)(typescript@4.9.4): | |||
| /cosmiconfig-typescript-loader@4.3.0(@types/node@14.18.36)(cosmiconfig@8.0.0)(ts-node@10.9.1)(typescript@4.9.4): | |||
There was a problem hiding this comment.
Users running pnpm install on an earlier version of pnpm might revert the preferred resolutions switched by pnpm dedupe from a later version of pnpm. We've noticed this flavor of problem cause confusion in PRs, when different versions of pnpm have slightly different dependency preferences and create unexpected pnpm-lock.yaml changes that are committed.
Just a heads up that differences in resolveDependencies logic across the same major version of pnpm can be surprising.
There was a problem hiding this comment.
this affects only the deduping optimization, so it shouldn't break any user, so I wouldn't expect a major version for such change (maybe a minor)
There was a problem hiding this comment.
It is already an issue as you can see. It randomly updates the versions of @types/node even though I did not touch @types/node. I am not sure even that this PR will fix all the issues related to this. Maybe we'll have to have another look at how preferred versions are selected.
There was a problem hiding this comment.
this affects only the deduping optimization, so it shouldn't break any user
The weights logic here affects both the pnpm install and pnpm dedupe code paths, which I think is the ideal. A lot of things become easier if the 2 commands have the same preferred versions logic. If these commands had different preferred versions logic, it'd be possible for pnpm install and pnpm dedupe to "fight" over changes and produce changes that revert each other with no eventual consistency. In practice this doesn't happen often since pnpm install won't edit pnpm-lock.yaml if no package.json files were updated, but it's still something to be mindful of.
Zoltan is correct that this is already a problem with pnpm install. I've seen this happen a few times, even on the same version of pnpm. It's less of a concern there because you'd have to edit a selector that affects the dependency graph of an ambiguous resolution.
I wouldn't expect a major version for such change (maybe a minor)
Perhaps? It's definitely an open question and might depend on team dynamics.
For one of the monorepos my team manages, we require pnpm to be on a chosen major version, but allow any minor and patch version within that major version. We're revisiting that decision a bit because it causes pnpm-lock.yaml changes in one PR to be produced that get changed/reverted in other PRs.
No description provided.