Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Updating package in workspace child project to the already hoisted version does not remove old version from the child node mods #3071

Closed
vgarba3 opened this issue Apr 13, 2021 · 5 comments
Labels
Bug thing that needs fixing Release 7.x work is associated with a specific npm 7 release

Comments

@vgarba3
Copy link

vgarba3 commented Apr 13, 2021

Current Behavior:

When using workspaces if two child projects share the same dependency but different versions the highest version (App1) is hoisted to the root nod_mods and the project (App2) with the lower version installs the package to its local node mods. The issue is that when / if the project (App2) with the lower version installed decides to upgrade its package to match the version that is already hoisted, that package is not removed from the lower/local node_mods, and it still resolves to the lower package version and can not be upgraded (with out manual work).

Workspace
  + node_modules
  |. + some-lib@1.1.0
  + App1
  |  + package.json
  + App2
  |  + package.json
  |  + node_modules
  |   |  + some-lib@1.0.0

When upgrade App2 some-lib@1.0.0 => @1.1.0, some-lib@1.0.0 is left in App2 node_mods

NOTE: version upgrade made through updating the package.json version, not the CLI

Expected Behavior:

When updating a projects dependencies, if the new package version matches the existing hoisted package version, the existing outdated package in the local child node_mods should be removed to allow the project to resolve to the hoisted package.

When upgrade App2 some-lib from @1.0.0 => @1.1.0, @1.0.0 should be removed from its node_mods

Steps To Reproduce:

  1. Create a simple project with workspaces set up and 2 child projects (App1, App2)
  2. Add the same dependency to both child projects but give App1 a higher version than App2
  3. npm install ( Note: The root node_mods should have the highest version from App1, and App2 should have the package in its node_mods )
  4. Update App2 dependency version to match App1 existing dep
  5. npm install

Test Repo: https://github.com/vgarba3/vg-npm-workspaces-deps

Notice that App2 can not resolve its updated version, and maintains it lower outdated package in its node modules.

Environment:

  • OS: macOS Catalina 10.15.7
  • Node: 15.4.0
  • npm: 7.7.6
@vgarba3 vgarba3 added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Apr 13, 2021
@vgarba3 vgarba3 changed the title [BUG] Updating package in workspace child project to the already hoisted version does not remove old version from the child node mods [BUG] Updating package in workspace child project to the already hoisted version does not remove old version from the child node mods Apr 13, 2021
@galtalmor
Copy link

I'm running into the same issue on my project. Hoping for a fix soon.

@timoxley
Copy link
Contributor

Workaround might be to remove package-lock and try reinstalling.

I think the core problem here is that it treats the package-lock as the source of truth and not at the package.json in the workspace. Maybe there's a way to update the package-lock with the updated linked version, or npm should ignore package-lock for workspace packages.

@vgarba3
Copy link
Author

vgarba3 commented May 11, 2021

@timoxley
Thank you for the response!
Yes that is unfortunately what we've been doing. Either that or just manually deleting the outdated package in the lower project. But its not sustainable for a large dev team to have to do this. For our specific situation this happens alot with our shared package that is updated quite regularly, causing outdate versions quite frequently.

@darcyclarke
Copy link
Contributor

@vgarba3 can you try replicating this problem on the latest version of npm? (ie. npm i -g npm); This should be fixed as of v7.15.0

@darcyclarke darcyclarke removed the Needs Triage needs review for next steps label May 28, 2021
@vgarba3
Copy link
Author

vgarba3 commented Jun 1, 2021

@darcyclarke Yep seems to be working as expected now - thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Release 7.x work is associated with a specific npm 7 release
Projects
None yet
Development

No branches or pull requests

4 participants