You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you npm i cli-example@1.0.0 in a project, it installs and you can verify in the package-lock.json that node_modules/istanbul-lib-instrument version is correct as 5.1.0 per configured in overrides.
The issue happens when installing said package globally, that is, npm i -g cli-example@1.0.0. In this case, checking the global npm folder for cli-example, under node_modules/istanbul-lib-instrument, the installed version is 5.2.1, ignoring the shrinkwrap defined version and installing the latest version available (5.2.1, as of this issue report).
According to this comment, #4889 (comment) if a dependency has shrinkwrap itself, overrides won't work, but this is not the case, I double checked the packages, they don't have shrinkwrap, so that specific scenario does not apply to here.
There's a related bug reported in Aug 2022 #5349 but in that one, it was demonstrated with a direct dependency rather than a transitive (though it does mention happening on transitive). My issue is similar, but in a way that this happens on global install, even if we lock the version on package (without ^).
This issue happened recently where a transitive dependency updated version and broke jest tests, therefore our CI pipelines were dead for the rest of the day due global installation updating it to latest, even though our package shrinkwrap had a lower version on it.
Expected Behavior
It is expected that a version number locked in package and shrinkwrap should be installed, instead of whichever number is latest, both in a direct installation (working as expected) and in global installations (this issue)
Steps To Reproduce
Create a directory, touch package.json and paste following content
verify in node_modules/istanbul-lib-instrument/package.json that installed version is 5.1.0
npm shrinkwrap
npm publish to the registry of choice (you can use verdaccio for local registry, remember to configure .npmrc)
npm i -g cli-example@1.0.0
Go to npm installation folder, browse cli-example folder, verify in node_modules/istanbul-lib-instrument/package.json that installed version is NOT 5.1.0(at the time of this issue, 5.2.1)
Environment
npm: both 9.8.1 and 10.2.3
Node.js: both 18.18.0 and 20.10.0
OS Name: Mac OSX 12.3.1 Monterey
System Model Name: Macbook Pro
npm config:
; "user" config from /Users/raphael.oliveira/.npmrc
//localhost:4873/:_authToken = (protected)
registry = "http://localhost:4873/"; node bin location = /Users/raphael.oliveira/.nvm/versions/node/v20.10.0/bin/node; node version = v20.10.0; npm local prefix = /Users/raphael.oliveira/Workspace/myCLI; npm version = 10.2.3; cwd = /Users/raphael.oliveira/Workspace/myCLI; HOME = /Users/raphael.oliveira
The text was updated successfully, but these errors were encountered:
This issue has been breaking my CI builds. Is there any workarounds for this? This happens for me without overrides. Shouldn't my dependencies in my shrinkwarp be honored?
Also experiencing this. Adding overrides made no difference either. Current workaround is to add the transitive dependency as a direct dependency with the required version.
Also experiencing this. Adding overrides made no difference either. Current workaround is to add the transitive dependency as a direct dependency with the required version.
We also just faced the same issue. It broke our CI build suddenly because the transitive dependency has breaking changes in minor release.
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
Issue is reproducible in v18.18.0 (npm 9.8.1) and latest v20.10.0 (npm v10.2.3)
Consider the following project
package.json
:installing and creating a
npm-shrinkwrap.json
will contains the correct version installed according to theoverrides
(aka5.1.0
):Now, when this package is published using
npm publish
(for the example, I'm using local registry w/verdaccio
), it lists correctly during publish:If you
npm i cli-example@1.0.0
in a project, it installs and you can verify in thepackage-lock.json
thatnode_modules/istanbul-lib-instrument
version is correct as5.1.0
per configured in overrides.The issue happens when installing said package globally, that is,
npm i -g cli-example@1.0.0
. In this case, checking the global npm folder forcli-example
, undernode_modules/istanbul-lib-instrument
, the installed version is5.2.1
, ignoring the shrinkwrap defined version and installing the latest version available (5.2.1, as of this issue report).According to this comment, #4889 (comment) if a dependency has shrinkwrap itself, overrides won't work, but this is not the case, I double checked the packages, they don't have shrinkwrap, so that specific scenario does not apply to here.
There's a related bug reported in Aug 2022 #5349 but in that one, it was demonstrated with a direct dependency rather than a transitive (though it does mention happening on transitive). My issue is similar, but in a way that this happens on global install, even if we lock the version on package (without
^
).This issue happened recently where a transitive dependency updated version and broke jest tests, therefore our CI pipelines were dead for the rest of the day due global installation updating it to latest, even though our package shrinkwrap had a lower version on it.
Expected Behavior
It is expected that a version number locked in package and shrinkwrap should be installed, instead of whichever number is latest, both in a direct installation (working as expected) and in global installations (this issue)
Steps To Reproduce
touch package.json
and paste following contentnpm i
node_modules/istanbul-lib-instrument/package.json
that installed version is5.1.0
npm shrinkwrap
npm publish
to the registry of choice (you can useverdaccio
for local registry, remember to configure.npmrc
)npm i -g cli-example@1.0.0
cli-example
folder, verify innode_modules/istanbul-lib-instrument/package.json
that installed version is NOT5.1.0
(at the time of this issue, 5.2.1)Environment
9.8.1
and10.2.3
18.18.0
and20.10.0
The text was updated successfully, but these errors were encountered: