Bundler's babel has an issue with ES2019 class #Identifier

[mrtipsytony]

👀 Please check the troubleshooting guide before reporting anything. It contains important information on how to fix or diagnose errors.

Issue type (mark with x)

• [x] :thinking: Question
• [ ] :bug: Bug report
• [ ] :gift: Feature request
• [ ] :woman_shrugging: Other

Version (mark with x)

• [ ] :three: v3.x
• [x] :two: v2.x

Description

Does the bundler support ES2019 "#identifer" in classes? We have a npm dependency package that the bundler cannot read.

I can only show the snippet for now and here it is:

The package is a web component ESM package and is imported as a side effect (e.g. import 'sample') to apply the shadow root to the markup.

Desired behavior: Bundler's babel to read es2019 class syntax

Current behavior: Bundler's Babel seems to have an issue with the files that has "#identifier"

Repro instructions (if applicable): Cannot disclose it but it's similar to this one: https://github.com/liferay/liferay-frontend-projects/issues/565

Other information (environment, versions etc):

[izaera]

The npm bundler supports ES5/CommonJS code, but I'm not against adding support for this syntax, as long as it is only related to parsing the files so that the bundler can continue doing its work. It seems the feature is already supported in all major browsers, thus the code should work at runtime.

We are currently using Babel 6, is there any plugin or configuration tweak available to make it support this syntax?

[mrtipsytony]

Thanks for your feedback!

I'm honestly not a babel expert but I do see some plugins online like babel-plugin-transform-class-properties or @babel/plugin-proposal-class-properties but I'm not entirely sure if the latter would be ideal since it still in "proposal" I guess.

Are we planning on upgrading to babel 7 later on? to support some ESM packages like the one we have.

[izaera]

Are we planning on upgrading to babel 7 later on? to support some ESM packages like the one we have.

I don't think so, TBH, because the way to go for newer versions will be using Client Extensions which build on top of JavaScript browser modules and import maps, so there won't be any need to use custom bundling tools at all :shrug: .

It is heavily under development, but you can see some examples of how it works here :point_right: https://github.com/liferay/liferay-portal/tree/master/workspaces/liferay-sample-workspace

This one https://github.com/liferay/liferay-portal/tree/master/workspaces/liferay-sample-workspace/client-extensions/liferay-sample-custom-element-4, for example, exercises a portlet rendered leveraging a standard custom element based on React. It would be similar to the portlets the regular @liferay/cli/liferay-npm-bundler provide.