Undetected duplicates across bundles

[tlvince]

According to the multiple entry points section in the readme, inspectpack will analyse all of the bundled files across all of the entry points. However, as of v4.5.2, this doesn't work as expected for me.

I've set up a reduced test case in https://github.com/tlvince/tlvince-sandbox-webpack-duplicates - there are two entry points each pulling in a different version of lodash. Inspectpack does not seem to detect these:

❯ yarn inspectpack -s dist/stats.json -a versions
yarn run v1.22.10
$ /tmp/tlvince-sandbox-webpack-duplicates/node_modules/.bin/inspectpack -s dist/stats.json -a versions
inspectpack --action=versions
=============================

## Summary
* Packages with skews:      0
* Total resolved versions:  0
* Total installed packages: 0
* Total depended packages:  0
* Total bundled files:      0
Done in 0.20s.

Another tool, webpack-stats-duplicates, does:

❯ yarn webpack-stats-duplicates dist/stats.json
yarn run v1.22.10
$ /tmp/tlvince-sandbox-webpack-duplicates/node_modules/.bin/webpack-stats-duplicates dist/stats.json
Duplicate module lodash found in webpack configuration 0
        ./packages/a/node_modules/lodash
        ./packages/b/node_modules/lodash

In the bundle analyser report:

Am I missing something or is this unsupported?

[ryan-roemer]

inspectpack presently focuses on bundles because that's the unit of work that you could potentially reduce duplication. In the example you have if we harmonize the versions of lodash, you'd still ship a separate copy of each, so in one sense version skew doesn't really matter as a usable tool to reduce your overall bundle size.

What most typically happens is that folks would take something like lodash and add it to a code split "vendor" module that both entry points depend on. inspectpack would then detect and report the duplicates as collapsing to a single lodash in the new vendor module would reduce overall application size / downloads.

We'd potentially be open to a feature of cross-bundle analysis, but would want to talk through the usefulness reporting-wise. Nearly all of what I typically use webpack for is analyzing bundles for things that could be reduced in size for any portion of the application, but we'd be open to hearing about other use cases!

[ryan-roemer]

You do have a good callout for this language:

Then the created stats.json object from the previous webpack-stats-plugin configuration will cause inspectpack to analyze all of the bundled files across all of the entry points.

which perhaps more succinctly could be refactored to:

Then the created stats.json object from the previous webpack-stats-plugin configuration will cause inspectpack to individually analyze each output bundle initiated by all of the entry points.

or something?