improvement: Display more detailed module information for concatenated entry modules

[pgoldberg]

Repro of this issue, also used to generate the bundle used in the test: https://github.com/pgoldberg/webpack-bundle-analyzer-concatenated-entry-modules

After migrating a large monorepo from Webpack 4 to Webpack 5, we noticed that we lost detailed entry module information, which made the bundle analyzer reports much less useful for us. After looking a little bit through the webpack-bundle-analyzer repo, I found this comment:

webpack-bundle-analyzer/src/analyzer.js

Lines 124 to 126 in e231c77

	// Webpack 5 changed bundle format and now entry modules are concatenated and located at the end of it.
	// Because of this they basically become a concatenated module, for which we can't even precisely determine its
	// parsed source as it's located in the same scope as all Webpack runtime helpers.

Although we can't determine the parsed sizes of the concatenated modules, we should show the estimated parsed and gzipped sizes for the concatenated entry modules like we do for other concatenated modules. More explanation of the issue here: #602 (comment)

Here's a before and after:

After this change, here is what that same view looks like:

[valscion]

Huh, that's a neat change with such a small change! Are you able to write up some sort of test to verify this behavior?

[pgoldberg]

Huh, that's a neat change with such a small change! Are you able to write up some sort of test to verify this behavior?

Yep I'll add a test!

[pgoldberg]

@valscion I added a test, and also updated the PR to include the modules contained in the concatenated entry module's graph for the parsed and gzipped reports, too.

After thinking a bit more about this I think this is actually a bug and a regression in webpack-bundle-analyzer from Webpack 4 to Webpack 5. On Webpack 4, entry modules that were themselves concatenated modules still showed (inaccurate) parsed and gzipped sizes when that box was ticked.

On Webpack 5, because we can't determine the exact parsed size of the entry modules, we create a concatenated module containing the entry modules. For those modules, we do get estimated parsed and gzipped sizes, because they're all ContentModules.

However, the entry modules themselves can be concatenated modules. In that case, because we've created the module as a ContentModule rather than a ConcatenatedModule, we're not getting estimated sizes for the modules within the concatenated entry module.

I believe this bug fix should only affect entry modules, because this type of situation only really occurs when an entry module is a concatenated module. I don't think webpack would ever output a real concatenated module that is itself a concatenated module – this only happens because of the synthetic concatenated module we create of all the entry modules that we can't accurately parse.

The test I added was generated using this minimal repro I made: https://github.com/pgoldberg/webpack-bundle-analyzer-concatenated-entry-modules

[pgoldberg]

This is modified from here:

webpack-bundle-analyzer/src/tree/ContentModule.js

Lines 18 to 24 in a4c304e

	getSize(sizeType) {
	const ownerModuleSize = this.ownerModule[sizeType];
	if (ownerModuleSize !== undefined) {
	return Math.floor((this.size / this.ownerModule.size) * ownerModuleSize);
	}
	}

[valscion]

Looks solid to me!

I have one wish regarding the example case that if possible, would make debugging this behavior later somewhat easier.

Also, could you update the changelog to include this change?

[valscion]

This would be easier to understand which module is which if the test repository you used could use different strings for each module rather than all using console.log("side effect") 😅

I think I do understand how this was generated and where the module boundaries are, though.

[valscion]

Also, if we would name this file app.js instead of bundle.js, then we could debug the output more easily also with locally built ./lib/bin/analyzer.js CLI:

./lib/bin/analyzer.js test/stats/webpack-5-bundle-with-concatenated-entry-module/stats.json

If I change this file name from bundle.js to app.js, then I can see the visualization of the bundle contents and can compare that to how current behavior looks like. Without renaming the file, I get this warning:

$ ./lib/bin/analyzer.js test/stats/webpack-5-bundle-with-concatenated-entry-module/stats.json
Error parsing bundle asset ".../webpack-5-bundle-with-concatenated-entry-module/app.js": no such file

No bundles were parsed. Analyzer will show only original module sizes from stats file.

[valscion]

Thanks, looks great!

[pgoldberg]

@valscion Thanks for the quick review! 😄

If you could cut a release whenever you get a chance, I'd really appreciate it 🙂

[valscion]

Yeah ran out of time yesterday, I usually cut releases almost straight away. I'll do a new release now :)

[valscion]

Released now in v4.9.0! ☺️

[pgoldberg]

Thank you!!