If the root package.json defines anyoverrides, if you attempt to update an un-hoisted dependency by editing the workspace's package.json and then running npm install, the new version doesn't actually get installed.
Critically, package-lock.jsondoes get updated when you do this, which may lead you to believe the new version was installed, but the old version still remains. This version mismatch can be detected by running npm ls (you'll get ELSPROBLEMS).
This has some similarities to #5850 -- in particular see this comment on an earlier issue which describes the same package-lock.json discrepancy -- but the key difference here is that the actual overrides don't matter, this issue is about the (mis)behavior of un-hoisted dependency resolution.
Expected Behavior
Editing a workspace's package.json and running npm install from the root should install the desired version(s) of dependencies, just as it does when you don't have any overrides.
Alternatively, npm install could detect the package.json <-> package-lock.json mismatch and tell the user to instead update the dependency via something like npm install <specifier> --save-exact -w <workspace>
Either solution would be vastly preferable to the current behavior where it appears to install the new version but actually keeps using the old one.
npm i tiny-invariant@0.0.2 --save-exact -w my-cool-package (hoisted to node_modules/tiny-invariant)
npm i tiny-invariant@0.0.3 --save-exact -w my-cool-package (un-hoisted to packages/my-cool-package/node_modules/tiny-invariant, seemingly due to #7019)
Edit packages/my-cool-package/package.json and change the tiny-invariant version to 1.3.1
Note that for steps 1 and 2, you can get the same behavior by editing packages/my-cool-package/package.json and running npm i; this only stops working once the workspace dependency is already un-hoisted (step 3)
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
If the root
package.json
defines anyoverrides
, if you attempt to update an un-hoisted dependency by editing the workspace'spackage.json
and then runningnpm install
, the new version doesn't actually get installed.Critically,
package-lock.json
does get updated when you do this, which may lead you to believe the new version was installed, but the old version still remains. This version mismatch can be detected by runningnpm ls
(you'll getELSPROBLEMS
).This has some similarities to #5850 -- in particular see this comment on an earlier issue which describes the same
package-lock.json
discrepancy -- but the key difference here is that the actual overrides don't matter, this issue is about the (mis)behavior of un-hoisted dependency resolution.Expected Behavior
Editing a workspace's
package.json
and runningnpm install
from the root should install the desired version(s) of dependencies, just as it does when you don't have anyoverrides
.Alternatively,
npm install
could detect thepackage.json
<->package-lock.json
mismatch and tell the user to instead update the dependency via something likenpm install <specifier> --save-exact -w <workspace>
Either solution would be vastly preferable to the current behavior where it appears to install the new version but actually keeps using the old one.
Steps To Reproduce
Given
package.json
:And
packages/my-cool-package/package.json
:Run:
npm i tiny-invariant@0.0.2 --save-exact -w my-cool-package
(hoisted tonode_modules/tiny-invariant
)npm i tiny-invariant@0.0.3 --save-exact -w my-cool-package
(un-hoisted topackages/my-cool-package/node_modules/tiny-invariant
, seemingly due to #7019)packages/my-cool-package/package.json
and change thetiny-invariant
version to1.3.1
npm i
Note this package-lock.json inconsistency:
Note that for steps 1 and 2, you can get the same behavior by editing
packages/my-cool-package/package.json
and runningnpm i
; this only stops working once the workspace dependency is already un-hoisted (step 3)Environment