build error if package contains ES2020 features (in this case, optional chaining)

[sndrs]

Type

Feature Request

support ES2020 in packages

Package name

@guardian/libs

Entire error (stringified) I see in my browser console

tmp/tmp-build/packages/build-@guardianlibs-VCG/node_modules/@guardian/libs/dist/esm/loadScript.js 15:8 Module parse failed: Unexpected token (15:8) File was processed with these loaders: * ./node_modules/shebang-loader/index.js You may need an additional loader to handle the result of these loaders. | }; | const ref = document.scripts[0]; > ref?.parentNode?.insertBefore(script, ref); | }); | @ /tmp/tmp-build/packages/build-@guardianlibs-VCG/node_modules/@guardian/libs/dist/esm/index.js 1:0-42 1:0-42 @ /tmp/tmp-build/packages/build-@guardianlibs-VCG/index.js

[pastelsky]

That is because webpack's parser (acorn) is going to fail to parse syntax. We do not transpile packages before webpack bundles them.

I think its a good idea for packages to not have a say on what client's babel configuration looks like. If you do want to ship with ES2020 or any such newer sytax, its better to use exports or the source field to let users opt into it.

[sndrs]

hi @pastelsky – thanks for taking the time to look at this issue!

I think its a good idea for packages to not have a say on what client's babel configuration looks like.

100% agreed, but I'm not sure they should also follow versions of acorn either? following specs, and requiring users to accommodate that, seems the only way forward (appreciate this is a hot topic with a lot of thought going into it at the moment)

that said, I think the latest webpack seems ok with ES2020 – I put together a demo at https://github.com/sndrs/webpack-es2020?

dist is prettified to make it easier to read, but you can see examples of nullish coalescing and optional chaining being handled ok.

[pastelsky]

I'm not sure I'd want bundlephobia to switch to Webpack 5 yet, as it appears that a lot of Webpack plugins/loaders don't fully support Webpack 5. For eg. there is still no stable version of Webpack Dev Server that works with Webpack 5 (months after webpack 5 release).

[dmnsgn]

Based on this comment webpack/webpack#10227 (comment), optional chaining will never be supported in Webpack 4 and the recommended course of action is to update to Webpack 5 or use a babel/ts transform.

---

@pastelsky
If I refer to https://github.com/pastelsky/package-build-stats/blob/master/package.json, all plugins and loaders listed there support Webpack 5 or are now Webpack 5 built-in optimisations (Terser). And webpack-dev-server isn't used?

I understand this involves a bit of refactor but shouldn't bundlephobia aim to support at least the current version of ES (ES2020)? Personally I have 5 packages failing because of nullish coalescing, optional chaining, top-level await and export ns from.

---

Also is it possible to add the originalError: to the server response? It could help understand the BuildError better.

[dmnsgn]

I see some work started here: pastelsky/package-build-stats#35
@pastelsky Is there any blocker for this to be completed or help needed?

[roypearce]

I'm not sure I'd want bundlephobia to switch to Webpack 5 yet, as it appears that a lot of Webpack plugins/loaders don't fully support Webpack 5. For eg. there is still no stable version of Webpack Dev Server that works with Webpack 5 (months after webpack 5 release).

Would you consider upgrading to Webpack 5 now?

[pastelsky]

Closing this as bundler updates are being discussed here —
#530 (comment)

Meanwhile, we've also upgraded our parser independently, and Bundlephobia should have no problem with ES2021+ syntax.
See https://bundlephobia.com/package/@guardian/libs

[sndrs]

thanks fantastic, thank you @pastelsky!