Config to not de-dupe during install #4037

aseemk opened this Issue Oct 24, 2013 · 7 comments


None yet
4 participants

aseemk commented Oct 24, 2013

I frequently run into cases where npm's default de-duping behavior during installs leads to issues and sometimes breaks.

I described a major one related to shrinkwrapping in issue #4036, but I figured I should make a separate issue for this general request, because the effects aren't isolated to shrinkwrapping.

Example: install A, then B, where B --> A:

npm init
npm install request@2.x
npm install strong-agent

A won't get installed currently under B, so if you then decide you no longer need A and uninstall it, you're in a broken state:

npm uninstall request
npm ls  # UNMET

Ultimately, the reason I ask this is because this default de-duping behavior makes npm installs unpredictable, and thus processes and workflows as a whole hard to reason about.

De-duping is also lossy — you can easily de-dupe by running npm dedupe, but you can't un-dedupe.

Because of this, it seems like it'd be most robust for npm to not de-dupe by default — you can always npm dedupe afterward if you want. But I understand people might not agree with that.

So at the very least, can we get a config to not de-dupe during installs? Thanks for the consideration!


rlidwka commented Oct 25, 2013

All these issues can be easily solved by running npm install after npm uninstall which is perfectly logical by the way. I don't know if it would make sense to do it by default, or just document this better.

The sad thing about this is that npm doesn't really dedupe by default. :(

aseemk commented Oct 25, 2013

Would you mind clarifying, @rlidwka? (npm uninstall by itself doesn't do anything.)

If you're referring to clearing all installed deps and re-installing, that doesn't do the trick either unfortunately. See for an example.


rlidwka commented Oct 25, 2013

After you do npm uninstall request in your example, you can run npm install in node_modules folder so npm will install request library again, one level higher this time:

npm init
npm install request@2.x --save
npm install strong-agent --save
npm uninstall request --save
npm install
npm ls  # should be ok

So yes, npm uninstall xx can leave the system in the unusable state, and there's nothing unpredictable about it.

If you do cd node_modules/strong-agent && npm uninstall async, do you still expect strong-agent to be functional? Same thing here.


rlidwka commented Oct 25, 2013

Hmm... that's funny, but my example above doesn't really work because of #1341 .

But still, it has nothing to do with deduplication.

aseemk commented Oct 28, 2013

I'm sorry, I'm not quite following.

If you do cd node_modules/strong-agent && npm uninstall async, do you still expect strong-agent to be functional?

That's intentionally going into a module and messing with its dependencies. My point here is exactly the opposite: you would expect nested dependencies to be implementation details, encapsulated away.

Simply put: if you install dependency A, then dependency B, should uninstalling A break B? Or vice versa?


rlidwka commented Oct 28, 2013

Nyaah, I surrender here.

I can imagine a few ways npm can do full deduplication and still handle all this correctly, but these are too hard to be implemented in current npm state.

So yep, current incomplete default deduplication is kinda weird.

iarna added this to the multi-stage install milestone Oct 10, 2014

iarna self-assigned this Oct 10, 2014


iarna commented Dec 12, 2014

This is going to be implemented under #6912. As such, I'm going to close this ticket and any further discussion should occur over there.

(Well, kind of-- this also relates fixing dependencies throughout the tree, which you'll find details on in #6913.)

iarna closed this Dec 12, 2014

iarna locked and limited conversation to collaborators Jun 24, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.