Open slavafomin opened 5 years ago
The issue is caused by Rush setting the pnpmOptions.resolutionStrategy = "fewer-dependencies"
instead of the pnpmOptions.resolutionStrategy = "fast"
, which is default in pnpm
.
I still believe that this behavior is very counter-intuitive in this case and caused a lot of trouble for us.
@slavafomin if you set resolutionStrategy:'fast' in rush.json does that solve the issue ?
@slavafomin My conclusion was that fewer-dependencies
is more correct, and less likely to encounter weird versioning problems.
Often you can tune this behavior using Rush's preferred versions setting. But it's hard to say from the information provided here.
If you could share a repro branch, I'm willing to debug it for you.
Hello!
Thanks again for your hard work!
We have a situation where transitive dependency version is selected incorrectly by Rush. I first thought that this is caused by
pnpm
, but after studying the issue further it occurred that actually Rush is responsible.Below, is the description of the issue that I've submitted earlier to the
pnpm
:There is a
@types/webpack-dev-server
package, which depends on@types/webpack@*
. We also have a direct dependency for@types/webpack@4.39.0
in our project. However, thepnpm
installs multiple versions of the@types/webpack
. In our root package it's4.39.0
(as specified), while in@types/webpack-dev-server
it's4.32.2
for some reason.There are other dependencies in our project which actually use the
4.32.2
version of the package in question. This explains where it comes from, but it doesn't explain why it's selected for@types/webpack-dev-server
instead of the latest one.1). Why
pnpm
is not resolving*
version specifier to the latest possible version of the package? Considering that more recent version is already installed in the root package.2). Is there a way to manually lock the version of the transitive dependency in question?
Here's the relevant information from the
pnpm-lock.yaml
:Could you elaborate on this please? Thank you.