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] workspace packages using different major versions of the same package causes issues #2783

Open
mesqueeb opened this issue Feb 26, 2021 · 6 comments
Labels
Bug thing that needs fixing Release 7.x work is associated with a specific npm 7 release

Comments

@mesqueeb
Copy link

I had originally posted this in feedback:
npm/feedback#236 (comment)

But was requested to post here as well:

Current Behavior:

TLDR;

I need to use multiple major versions of a single package. For this the only solution is a noHoist option, which I can't seem to find for NPM7 workspaces.

My case:

I have a NPM7 monorepo that holds a core lib focussed on data communication with a plugin system.
Some plugin in my workspace in ./packages use an NPM package (let's call it Y) of major version 2, while another uses Y of major version 3.

When the "docs" SPA in ./packages uses Y at v2 as well as the plugin that uses Y at v2, the docs cannot be launched because it's giving a conflict for version of package Y. It tries to use Y at v3.

How can I prevent "Y" from being hoisted in the NPM7 workspace? It's the only issue.

Expected Behavior:

I expect to be able to

Steps To Reproduce:

I can try to set up a repo that replicates this if requested.
I had already have to stop using workspaces because of this issue, so I don't have a reproduction ready to go. But am willing to create one if requested.

Environment:

npm: 7.5.6
macOS: 11.1

@mesqueeb mesqueeb 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 Feb 26, 2021
@mesqueeb
Copy link
Author

mesqueeb commented Mar 4, 2021

Any other info required ?

@mesqueeb
Copy link
Author

nohoist would fix this issue btw...

@darcyclarke
Copy link
Contributor

darcyclarke commented Apr 9, 2021

@mesqueeb we're still looking into this at the moment but when method that might help you, as a stopgap, is to run npm install with the flag --legacy-bundling; This will nest deps relatively but eliminate deduping.

@darcyclarke darcyclarke removed the Needs Triage needs review for next steps label Apr 9, 2021
@strelga
Copy link

strelga commented Apr 14, 2021

@darcyclarke
Lack of the feature like nohoist or similar blocks my team from moving to npm 7 in our monorepo as well.
Do you have it in your roadmap for near future?
Maybe it is in some coming RFC?

@mesqueeb
Copy link
Author

@darcyclarke it seems that has resolved the issue for me. What happens if a team mate forgets to add that flag when doing npm i on the repo? is there a way to force that flag whenever someone does npm i on the repo?

@ljharb
Copy link
Contributor

ljharb commented Apr 19, 2021

@mesqueeb add legacy-bundling=true to .npmrc

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