-
Notifications
You must be signed in to change notification settings - Fork 3k
cache-min & unknown version #8581
Comments
@othiym23 what are your reservations about this? |
Arrrrrgh! I keep running into this, too. 😡 e.g.
Here, |
We chatted more about this internally and reservations are withdrawn– We would welcome a patch that, if a dependency version lookup failed with a cached version of the package's metdata, tried again with a fresh version. (This may be a bit tricky due to the architecture around the config being a painfully global object, but with sufficient surgery it's plausible.) However, it's not on our timeline for the coming year to add it ourselves. As such, @othiym23 has marked this patch-welcome, and I'm going to close this issue. |
When a package is fetched from the cache which cannot satisfy the version requirements, an attempt to fetch it fron the network is made. Fix npm#8581.
For the record, I disagree that this issue should be closed, and I disagree with labelling it as a "feature request". It's a race condition bug that sometimes causes a completely valid |
Also for the record: this issue was fixed by #12084 which was released in npm 3.9. |
Has there been a regression? We are currently using 3.10.8 and this logic is no longer working. we have cache-min=Infinity and after publishing a new version of a dependency (e.g 1.0.7), running npm install dep@1.0.7 gives an error ETARGET. |
I'm still experiencing this at v4.1.2, with
|
Currently, if npm is trying to install a package not yet in the npm cache, it will reach out to the registry and grab the package, even with
cache-min=Infinity
. This is desirable.This allows high values for cache-min to work well, but a problem occurs in the following scenario:
npm install --cache-min=Infinity
To resolve this, one has to update the cache's version info e.g.
npm info packagename
or lower thecache-min
setting. This makes use of highcache-min
values particularly error prone, especially on first installs.It would be good if unknown versions were treated the same as unknown package names, i.e. npm should fall back to checking the remote registry before reporting "no compatible version found".
The text was updated successfully, but these errors were encountered: