webpack-contrib / webpack-bundle-analyzer

Webpack plugin and CLI utility that represents bundle content as convenient interactive zoomable treemap

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

error tolerant configuration of acorn parser

jbjhjm opened this issue · comments

Issue description

Angular production bundles use the encoded ɵ char (\u0275) for Ivy-generated methods.
In some cases, acorn parser will falsy detect use of a reserved keyword and throw a SyntaxError.
(happens in source code bits like let \u0275FaqFrontendFeature_BaseFactory, seems the leading \u0275 makes acorn not detect the variable name, let will be treated as whole statement, which would be erronous.)

Technical info

This is stripped down content of an angular chunk file which would make webpack-bundle-analyzer fail because acorn throws an error.

"use strict";
(self.webpackChunkmpf_frontend = self.webpackChunkmpf_frontend || []).push([
	[573], {
		83302: (__unused_webpack_module, __webpack_exports__, __webpack_require__) => {
			return function () {
				let \u0275ProgressBar_BaseFactory;
			}()
		},
	}
]);

Proposed solution

It is not webpack-bundle-analyzer's task to validate source files.
Because of that, I propose to update the configuration of acorn parse runner to tolerate such errors and not throw.

In parseUtils.parseBundle, the acorn.parse options object can be detailed by setting allowReserved:true.
This will make acorn tolerate reserved keywords and analyzation can continue.

function parseBundle(bundlePath) {
  const content = fs.readFileSync(bundlePath, 'utf8');
  const ast = acorn.parse(content, {
    sourceType: 'script',
	allowReserved:true,
    // I believe in a bright future of ECMAScript!
    // Actually, it's set to `2050` to support the latest ECMAScript version that currently exists.
    // Seems like `acorn` supports such weird option value.
    ecmaVersion: 2050
  });
  // ...

Thanks for the detailed issue! Looks like it can be fixed quite easily, so PR is welcome.

@th0r alright, will do as soon as I find some time!

Was going to look into this again and open a PR.
But I found that it is working fine again, at least with angular 15.
So it was fixed in some way in the meantime, means I'm closing this!