Duplicate modules - NOT solvable by `npm dedupe`

Do you want to request a feature or report a bug? Bug

What is the current behavior? Two identical sub-dependencies are being included twice in the build.

If the current behavior is a bug, please provide the steps to reproduce. projectA depends on libA@^2.0.0, depA and depB. depA and depB both depend on libA@^1.0.0

This results in a directory structure like this:

projectA
- node_modules
-- libA
-- depA
---- node_modules/libA
-- depB
---- node_modules/libA 

When the project is built, included in the bundle are:

libA@2.0.0
depA
depB
libA@1.0.0
libA@1.0.0

What is the expected behavior? The included modules should be:

libA@2.0.0
depA
depB
libA@1.0.0

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System. webpack@3.5.5

I have run npm dedupe but it can’t fix the problem. This is understandable, because npm doesn’t have anywhere to “put” this lower-version dependency that is shared by both depA and depB. Previously I believe this was solved with the DedupePlugin which has since been turned into a no-op.

[franjohn21]

It doesn’t look like it was ever provided, so I created a repo that shows a simple example of this issue: https://github.com/franjohn21/dedupe-example

FWIW the code being webpacked in that example does not use harmony modules, so ideally webpack 2/3 could maintain parity with webpack 1.

We consistently see higher (>10%) bundle sizes in production apps at NerdWallet when migrating from webpack 1 -> webpack 3 mostly due to this issue.

[tomhicks-bsf]

Thing is, I didn’t choose to install the package twice, and there is no way for me to “fix” this at the package manager level, as you’ve suggested in other issue threads.

Wepback used to solve this problem in v1 with DedupePlugin, so this seems like a regression of sorts. The docs say that the DedupePlugin is no longer needed, which implies that it will do some kind of deduping of its own.