[core] Use out-file-extension to build esm version

[merceyz]

• I have followed (at least) the PR section of the contributing guide.

Updated @babel/cli to make use of https://babeljs.io/docs/en/babel-cli#set-file-extensions when building the ESM version of the packages.
Thanks @eps1lon

This enables treeshaking on all levels and simplifies the build script since we don't need to create a package.json file in the subfolders anymore.
Even though we consider 3rd level imports private, there is nothing stopping people from using them, so they do. This will benefit them with reduced bundle sizes

For backwards compatability it still builds the esm folder which we can remove in v5

[eps1lon]

Nice, that was the original plan with this cli feature. I'm hesitant shipping even more files though. As far as I can tell e.g. /core/Button/Button.mjs and /core/esm/Button/Button.js are now identical?

Considering that we have to realize that the internal file structure is used for aliases (be it webpack or typescript) I would rather wait for v5 and simplify the structure while working on #18447.

The goal is to have { "type": "commonjs" } and .d.ts, .js, .mjs (and .node) in a single folder. But since this concerns build setups (which nobody likes to touch) I would caution against touching it until the next major.

Unless this solves an existing issue?

[TrySound]

This will create the issue with webpack. material-ui-pickers will be forced to use commonjs version of material-ui. Moreover webpack is very confused when finds mjs extension in package.json "module" field. I recommend to not deal with mjs unless you setup package.json "exports" field

[eps1lon]

Moreover webpack is very confused when finds mjs extension in package.json "module" field. I recommend to not deal with mjs unless you setup package.json "exports" field

Not my experience with webpack. I even tested it months ago. Could you link to an existing issue or reproduction?

[TrySound]

One of them. The main problem is overusing "default" exports.
webpack/webpack#7973

[eps1lon]

One of them. The main problem is overusing "default" exports.
webpack/webpack#7973

That repro does not contain any .mjs files. The example with a module entry seems to mimic rollup output which is considered correct? This is how we would do it.

Please provide a complete example illustrating the issue you described. You were pretty fast with that conclusion so a repro should be fast to set up as well.

[merceyz]

As far as I can tell e.g. /core/Button/Button.mjs and /core/esm/Button/Button.js are now identical?

Yes, that is correct

I would rather wait for v5 and simplify the structure while working on #18447.

That's totally fine by me.

Unless this solves an existing issue?

Enables treeshaking on the 3rd level, so it would solve the issues that are opened due to people importing from that level and getting duplicated modules.

[eps1lon]

Thanks for the work 👍

Closing for housekeeping though. Will revisit for v5 as we don't want to publish more files than necessary. We want to keep the count as low as possible for codesandbox (ci and actual).

[oliviertassinari]

👍 for taking http://packagephobia.now.sh/ size into consideration.