[ESM] Publish packages in ESM module format

[Janpot]

Why

• Run untranspiled on server environments (e.g. Next.js experimental.esmxternals). Could help with [styled-engine-sc] MUI + styled-components + Next.js CSS rules ordering issue #29742 (comment) to give babel-plugin-styled-components a source that is easier to statically analyze.
• Snowpack has trouble serving our library: Compilation error caused by "circular reference" (@mui/core, @mui/core/ModalUnstyled) #28628
  It looks like it’s trying to convert back the commonjs version into ESM and getting confused (this is a non-deterministic process, best effort). It seems to resolve the package specifier to the commonjs module instead of ESM
• Next.js supports ESM by default in v12
• Issues with vite module ordering which seem to get resolved when packages have exports defined
• Issues around mixed cjs/esm imports when using icons-material both in Next.js and vite [ESM] @mui/icons-material move to pure ESM #35233

How

• Early attempt: Draft: Try converting packages to ESM #30510

• Figure out what happened with these PRs and verify whether the problem is still relevant:

  • [icons] Only ship ES modules #26310
  • Revert "[icons] Only ship ES modules (#26310)" #26656

• In our build output, make sure ESM files get the extension .mjs. We can probably start with this and maybe even release on a minor

• package.json: dual ESM/commonjs: https://nodejs.org/api/packages.html#dual-commonjses-module-packages

  • Add exports field, let's leave out the "type": "module" until v7?
  • We should do this one one major (v6)

• Internal imports will need file extensions https://github.com/jaydenseric/babel-plugin-transform-require-extensions. We can probably also consider releasing this on a minor version

• How do we deal with process.env.NODE_ENV (e.g. https://github.com/mui-org/material-ui/blob/1230b1a571942f1abf2fec81812b757ceb0e5d0b/packages/mui-system/src/spacing.js#L104)? It will break when run as a module in the browser.
  Perhaps:

  // This way it won't break uncompiled, but webpack can still 
  // replace `process.env.NODE_ENV`
  import process from './process'
  
  // ...
        if (process.env.NODE_ENV !== 'production') {
          if (typeof abs !== 'number') {
            console.error(
              `MUI: Expected ${propName} argument to be a number or a string, got ${abs}.`,
            );
          }
        }
  // ...
  
  // ./process.js
  // Gracefully handle being run in the browser
  export default typeof process === 'undefined' ? { env: {} } : process;

• This doesn't work with react <=17: Bug: Cannot import 'react/jsx-runtime' from esm node/webpack 5 facebook/react#20235, We may be stuck on this until package exports are backported to react 17 (or when we can bump our react peer dependency >=18).

[MicahZoltu]

Internal imports will need file extensions https://github.com/jaydenseric/babel-plugin-transform-require-extensions

I think this should probably be extracted out into a separate issue, as it would be a boon to using Material UI natively in a browser (without a bundler/transpiler), I think even without addressing the other things mentioned here (I could be wrong though).

[cseas]

Publint is reporting that the components are written in ESM but getting interpreted as CJS.

I tried the MUI imports in a Next.js project with type: module and moduleResolution: node16 though, seems to work fine. (https://codesandbox.io/p/sandbox/angry-benji-oi33ry)

Is this because Next.js is reading the CJS exports under node/ directory instead of ESM ones?

[zwn]

In order to be able to use @mui/icons-material in ES module (with remix), I had to use named import:

import { LockOutlined } from '@mui/icons-material';

I believe it relies on the presence of "module": "./esm/index.js" field in the installed package.json which reexports everything. Reaching out to @mui/icons-material/LockOutlinedIcon like the examples do, fails.

[samuelsycamore]

This seems to be a blocker for getting MUI components to play nicely with Remix. Named imports appear to work fine.

❌ import Box from "@mui/joy/Box";
✅ import { Box } from "@mui/material";

[cjoecker]

As a workaround, you can do for now the following search-and-replace with regex to fix it:
Search import (.*)Icon from "@mui/icons-material/(.*)"; and replace with import { $1 as $1Icon } from "@mui/icons-material";

[akomm]

Output .cjs file, set it under package.json should make it possible use it with tsconfig esModuleInterop: true. Currently you can't do anything in esm configured project, because there is just a .js file in the build. And this .js file uses esm syntax.

Having this issue with the AdapterXYZ exports - date-pickers.

[oliviertassinari]

Requirement for both CommonJS and ESM support from Docker: https://app.supernormal.com/posts/mui-docker-x-charts-6b722290c9c8013c6d350e8110019023

[Janpot]

Would be interested in what those infrastructure requirements are exactly. What mandates the need for a commonjs bundle? Does their bundler not understand ESM? Or does their SSR setup not compile modules on the server? It's an odd choice to try and fix this by adding a commonjs version to their chart library, rather than to force their bundler to transpile the dependency.

[DiegoAndai]

Sadly, I'm removing this issue from the v6 milestone, tentatively moving it to v7. I'll write an in-depth document on what we tried, why we're blocked, and the steps forward. As a summary, we found a blocker with NextJS Pages Router: vercel/next.js#65056. The probable path forward is removing the esmExternals: false from our documentation infra, but that's currently blocked by vercel/next.js#49898 (comment)