Parsed/gzip analysis missing majority of one bundle

[pjlee11]

Issue description

For a single bundle of our application we are seeing the bundle analyzer report show the parsed/gzip value with the majority of the bundle missing. It also worth noting I've run this with the webpack-bundle-analyzer CLI (as per the docs) and there are no errors, which makes me believe it's a different issue. In the screenshot below we can see the stationtostation bundle reporting everything as expected in the stat tab.

However, when hovering over src/client/ we can see both the parsed and gzip size is 0B.

This can't be the case because all of the code in that bundle runs as expected and application runs as expected with a gzipped version of this bundle. Also worth noting that the bundle analyzer can correctly read the parsed/gzip of the whole bundle, just isn't showing it's internal parts correctly.

Technical info

• Webpack Bundle Analyzer version: 3.7.0
• Webpack version: 4.41.2
• Node.js version: 12.5.0
• yarn version: 1.22.4
• OS: macOS Mojave v10.14.6

Debug info

Tried as both plugin and CLI:

webpack --config webpack.production.config.js --profile --json > stats.json
npx webpack-bundle-analyzer stats.json

      new BundleAnalyzerPlugin({
        analyzerMode: 'static',
        reportFilename: path.resolve(__dirname, `temp/report-bundle-analyzer-js.html`),
        openAnalyzer: false,
      }),

What other Webpack plugins were used?
ManifestPlugin
webpack.EnvironmentPlugin (also tried as webpack.DefinePlugin)

It would be nice to also attach webpack stats file....
stats.json.zip

This analyzer output is triggered by us adding a process.env variable via the webpack EnvironmentPlugin however the way this variable is used in the application shouldn't have an affect on the bundles, it's just normal JS.

[valscion]

Hmm strange... would you be able to pull together a minimal reproduction? In this case, we will need access to the bundled output files to figure out what is going wrong when parsing their contents. It seems like the parsing succeeeds somewhat (given there even is the text "Parsed size" and "Gzipped size" in the tooltips) but for some reason, webpack-bundle-analyzer calculates the module's contents to be zero-bytes long.

Maybe all of the source code might be mushed together for some reason, with webpack concatenating all of the modules to single module? If this would be the case, then we would indeed be able to only show the topmost size as the parsing would fail to dive deeper given webpack has removed all information about module boundaries in the resulting output.

[pjlee11]

The rest of the application is split correctly into bundles by webpack and those have the correct stat/parsed/gzip information all shown as usual with the analyzer. It's one bundle in particular. The browser still downloads and runs all the bundles as expected with gzip being served. I can see the files for that particular bundle exist and are in the right file path.

I'll have a little dig to see if I can make a small reproduction

[valscion]

Thanks! Maybe this helps:

The tests for bundle contents are in this repository here: https://github.com/webpack-contrib/webpack-bundle-analyzer/tree/master/test/bundles

These test that the output bundle can be parsed back to modules. Once we have the modules rebuilt, webpack-bundle-analyzer calculates the parsed and gzipped sizes from there.

For example, this output bundle:

webpack-bundle-analyzer/test/bundles/validWebpack4AsyncChunkUsingSelfInsteadOfWindow.js

Line 1 in 06e6b39

(self.webpackJsonp=self.webpackJsonp||[]).push([[27],{1:function(e,n,t){console.log("Chuck Norris")}}]);

is parsed to a module list like so:

webpack-bundle-analyzer/test/bundles/validWebpack4AsyncChunkUsingSelfInsteadOfWindow.modules.json

Lines 1 to 5 in 06e6b39

	{
	"modules": {
	"1": "function(e,n,t){console.log(\"Chuck Norris\")}"
	}
	}

---

So if you're able to figure out the minimal required bundle output that the module list does not match, you could create a test case with adding these two files. The tests should be broken to show that there's support missing for some specific output case.

Then what's left to do is to explain clearly what kind of webpack configuration could make the output bundle look like the test file looks like — that's valuable information to know if there's issues later on about the specific bundle parsing logic.

Once there's a failing test case, a fix looks similar to this: #68. Mostly the src/parseUtils.js file needs to have more logic to be able to parse the specific output correctly.

[pjlee11]

The more digging I've done the more I think this is a probably with an internal package and the analyzer. Which makes it much harder to create a test case for and that it's likely a problem our end. Thanks for the quick responses it's really appreciated 😄