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 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.
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.jsondefines anyoverrides, if you attempt to update an un-hoisted dependency by editing the workspace'spackage.jsonand then runningnpm 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 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.jsondiscrepancy -- 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.jsonand runningnpm installfrom the root should install the desired version(s) of dependencies, just as it does when you don't have anyoverrides.Alternatively,
npm installcould detect thepackage.json<->package-lock.jsonmismatch 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:{ "workspaces": [ "packages/*" ], "overrides": { "doesnt-matter-can-be-anything": "1.2.3" } }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 [BUG] presence ofoverridesprevents hoisting when updating workspace dependencies #7019)packages/my-cool-package/package.jsonand change thetiny-invariantversion to1.3.1npm iNote that for steps 1 and 2, you can get the same behavior by editing
packages/my-cool-package/package.jsonand runningnpm i; this only stops working once the workspace dependency is already un-hoisted (step 3)Environment