Open tlvince opened 3 years ago
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!
You do have a good callout for this language:
Then the created
stats.json
object from the previouswebpack-stats-plugin
configuration will causeinspectpack
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 previouswebpack-stats-plugin
configuration will causeinspectpack
to individually analyze each output bundle initiated by all of the entry points.
or something?
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:
Another tool, webpack-stats-duplicates, does:
In the bundle analyser report:
Am I missing something or is this unsupported?