support webpack@5

[alexander-akait]

Issue description

...

Technical info

• Webpack Bundle Analyzer version: latest
• Webpack version: next (5)
• Node.js version: 10.13.0
• npm/yarn version: npm 6.13.4
• OS: Linux Ubuntu

Debug info

Support webpack@5 (will be great have CI and fix test to ensure all works as expected)

---

Additional comment by @valscion in #327 (comment):

This one for example has been open almost a year, and the webpack v5 stable release was over a month ago.

Do note that webpack-bundle-analyzer does work with webpack version 5. There is some combination of options which breaks, but not all of webpack 5.

We even test that this package works with webpack v5: https://github.com/webpack-contrib/webpack-bundle-analyzer/tree/master/test/webpack-versions/5.4.0

So this is only an edge case that is broken, not the entire support for webpack 5.

[valscion]

I wonder what's needed to support webpack 5? What kinds of failures are there when running with webpack 5 currently?

[alexander-akait]

Some developers from webpack/webpack#9802 say what webpack-bundle-analyzer doesn't work with webpack@5, will be great setup CI to ensure all works fine, also acorn should be updated 😄

[valscion]

Ok thanks for pointin to that issue! That one is a doozy, 281 comments as of now 😅

[valscion]

I don't see a mention in webpack/webpack#9802 to webpack-bundle-analyzer, care to point to any specific comment if someone has said that there's an issue?

This repository only has a development dependency to webpack as it's used only in a few tests. Mostly we rely on stats files generated from various webpack versions instead of running CI with multiple different webpack versions.

[alexander-akait]

@valscion Can we add webpack@5 stats as test for CI, just want to ensure all works fine

[valscion]

Oh, actually, I mean that instead of stats, we use bundles generated by different versions of webpack. In specific cases, there are stats also but the most brittle piece of code relates to generated bundle parsing and module extraction from there.

https://github.com/webpack-contrib/webpack-bundle-analyzer/tree/master/test/bundles contains those tests and are automatically used in tests in pairs:

webpack-bundle-analyzer/test/parseUtils.js

Lines 8 to 25 in 7cefb58

	describe('parseBundle', function () {
	const bundles = fs
	.readdirSync(BUNDLES_DIR)
	.filter(filename => filename.endsWith('.js'))
	.map(filename => filename.replace(/\.js$/u, ''));
	bundles
	.filter(bundleName => bundleName.startsWith('valid'))
	.forEach(bundleName => {
	it(`should parse ${_.lowerCase(bundleName)}`, function () {
	const bundleFile = `${BUNDLES_DIR}/${bundleName}.js`;
	const bundle = parseBundle(bundleFile);
	const expectedModules = JSON.parse(fs.readFileSync(`${BUNDLES_DIR}/${bundleName}.modules.json`));
	expect(bundle.src).to.equal(fs.readFileSync(bundleFile, 'utf8'));
	expect(bundle.modules).to.deep.equal(expectedModules.modules);
	});
	});

[valscion]

So basically the easiest way we could have more assurance that webpack @ 5 works would be to create small bundles made with webpack 5 and write out the expected modules JSON next to the bundle output.

I don't have time to do that right now, but if you or someone else is willing to add this kind of small test case for webpack@5, it would be nice ☺️

[sokra]

webpack has a different output AST so the parser need to be adjusted. It also gets a little bit more challenging as more variations are possible:

/******/ (() => { // webpackBootstrap
/******/ 	var __webpack_modules__ = ([
MODULES HERE
/******/ 	]);

/******/ (() => { // webpackBootstrap
/******/ 	"use strict";
/******/ 	var __webpack_modules__ = ([
MODULES HERE
/******/ 	]);

(() => {
	var e = [
MODULES HERE
        ], r = {};
	function t(o) {
		if (r[o]) return r[o].exports;
		var n = (r[o] = { exports: {} });
		return e[o](n, n.exports, t), n.exports;
	}

Arrow functions may also be normal functions when output.ecmaVersion: 5.

Arrays might be objects too, as with webpack 4.

There might also be one entry module inlined into the runtime code, which is very difficult to identify in production mode.

[valscion]

Thank you @sokra for the extensive information! This looks like something we can work with.

Seems like what we could do would be to pick the modules from the first variable definition in the bundles when the other conditionals have failed.

We already handle both arrays and objects form of modules, so we only need to change the code to find modules from the variable and then do the parsing as before.

If we fail to parse some output bundles, the analyzer will just show the original module size from the stats file. So we should get a graceful degradation instead of a bad crash.

[a-x-]

Seems, analyzer works with webpack 5 beta 12 now

[Linksku]

After upgrading to webpack@^5.0.0-beta.22, webpack-bundle-analyzer just shows a single main.js, while other packages such as webpack-visualizer are able to display my files correctly. The content of stats.json looks normal.

Interestingly, after I added back Webpack 4 with yarn add webpack4@npm:webpack@latest, using webpack4 to generate stats.json produces the same issue of a single main.js. If I completely remove Webpack 5, then webpack-bundle-analyzer works again.

Any ideas on how to build using Webpack 5 normally, but use Webpack 4 just for webpack-bundle-analyzer?

[jaydenseric]

I haven't fully debugged it yet, but this seems to cause an error with webpack v5:

webpack-bundle-analyzer/src/BundleAnalyzerPlugin.js

Line 137 in d093666

switch (this.compiler.outputFileSystem.constructor.name) {

    TypeError: Cannot read property 'name' of undefined

      at BundleAnalyzerPlugin.getBundleDirFromCompiler (node_modules/webpack-bundle-analyzer/lib/BundleAnalyzerPlugin.js:142:56)
      at BundleAnalyzerPlugin.generateStaticReport (node_modules/webpack-bundle-analyzer/lib/BundleAnalyzerPlugin.js:134:23)
      at node_modules/webpack-bundle-analyzer/lib/BundleAnalyzerPlugin.js:64:33
      at node_modules/webpack-bundle-analyzer/lib/BundleAnalyzerPlugin.js:73:53
          at Array.map (<anonymous>)
      at Immediate.<anonymous> (node_modules/webpack-bundle-analyzer/lib/BundleAnalyzerPlugin.js:73:39)

[valscion]

Looks the same as #384

[jaydenseric]

I'm trying to update size-limit to webpack v5 (to fix ai/size-limit#205), but this is a blocker. size-limit uses this plugin for the --why flag.

[valscion]

Please help #384 go through by adding tests and discover more information on why that code is necessary. Then we can merge it once we understand why it is needed and if it can have any tests.

[jaydenseric]

Please help

I don't have the availability, sorry. I'm already fixing an issue with a project by fixing an issue with a package, that requires a fix to another package, which in turn requires another package fixed 🥲

It's a bit strange; almost no one must be using webpack v5 given the lack of movement on some of these issues. This one for example has been open almost a year, and the webpack v5 stable release was over a month ago.

[valscion]

This one for example has been open almost a year, and the webpack v5 stable release was over a month ago.

Do note that webpack-bundle-analyzer does work with webpack version 5. There is some combination of options which breaks, but not all of webpack 5.

We even test that this package works with webpack v5: https://github.com/webpack-contrib/webpack-bundle-analyzer/tree/master/test/webpack-versions/5.4.0

So this is only an edge case that is broken, not the entire support for webpack 5.