[core] Convert scripts to ES modules

[michaldudak]

Converted applicable scripts from the /scripts directory to ESM.
Contents of the scripts/sizeSnapshot directory were not converted because they were used by Danger. The dangerfile can't be an ES module.

Also renamed a few scripts for better consistency (kebab-case to camelCase).

[mui-bot]

	Fails
🚫	node failed.

	Messages
📖	Netlify deploy preview: https://deploy-preview-35036--material-ui.netlify.app/

Log

danger-results://tmp/danger-results-0d77b8cd.json

Generated by 🚫 dangerJS against 6c8e1e8

[michaldudak]

@mui/toolpad, @mui/x please verify if your projects are affected by these changes.

[Janpot]

Minor changes required mui/mui-toolpad#1307

edit: pleasantly surprised to see you didn't have to resort to createRequire even once

[Janpot]

Contents of the scripts/sizeSnapshot directory were not converted because they were used by Danger. The dangerfile can't be an ES module.

@michaldudak I notice the dangerfile runs async code. It's possible to dynamically import() ESM inside commonjs, this shouldn't be too hard to convert. (keep the dangerfile cjs, but all imports ESM)

https://nodejs.org/api/esm.html#import-statements

import statements are permitted only in ES modules, but dynamic import() expressions are supported in CommonJS for loading ES modules.

[michaldudak]

@Janpot thanks for the tip! I'll try it out.

[Janpot]

🤦 looks like danger is compiling it down to commonjs before running it

edit: danger/danger-js#1180

[michaldudak]

Yep, it won't fly this way..

[michaldudak]

I reverted the changes done to the sizeComparison directory. It's a CJS module again.
It's not problematic for now but will be if any of the dependencies these scripts use are converted to ESM only package.

[michaldudak]

I also reverted changes to buildColorTypes. It's not really a proper ES module as it imports packages\mui-material\src\colors\index.js, which is a CJS module that uses export syntax and thus must be transpiled by Babel. The .mjs extension could cause confusion, so I decided not to use it.

@Janpot I assume there's no way to import such a not-ESM-but-also-not-CJS-either file in Node but if you happen to know any tricks, I'll be happy to learn.

[Janpot]

The module packages\mui-material\src\colors\index.js is in ESM format, but the package @mui/material is not. When node tries to resolve @mui/material/colors, it can't find it because:

• @mui/material is not ESM (no "type": "module" in package.json)
• @mui/material doesn't have an export defined for colors in package.json

For this to resolve correctly, we first need to make the MUI packages proper ESM (I started that effort here, but it's gone a bit stale by now #30510, basically we need to add "type": "module" and "exports" in all package.json and make sure our import specifiers use file extensions everywhere)

It's possible to import CJS in ESM, so if the package has been built, the following works:

// @mui/material/build/colors/index.js is a commonjs module
import * as colors from '@mui/material/build/colors/index.js';

Not a great solution though, and eslint won't like it neither

[michaldudak]

The module packages\mui-material\src\colors\index.js is in ESM format

The way I understand it is it doesn't have file extensions in exports, so it's not exactly a valid ES module. Babel does handle it, but Node needs file extensions.

[Janpot]

it doesn't have file extensions

Right, good catch 👍.

edit: If I'm not mistaken, module resolution is not part of the ecmascript specification. It's valid ESM, node.js just doesn't know how to handle the specifier (Not that it matters in how we handle the problem here 🙂 )

[michaldudak]

@LukasTy, @Janpot now that this is merged, you can go ahead and merge the PRs in your projects.