[code-infra] Update package layout for better ESM support

[Janpot]

Bringing mui/material-ui#43264 to X. This is a breaking change.

Updates to the package layout:

• flatter layout with
  • ./index.js => cjs
  • ./esm/index.js => esm
  • ./modern/index.js => modern
• package.json exports to route bundlers and runtimes to the correct module
• depends on [code-infra] Fully resolve imports in ESM target #14234 for full ESM support. This will make the packages importable in native Node.js ESM if you so wish.

to do

• manual integration testing https://github.com/Janpot/esm-integration-x

[mui-bot]

Deploy preview: https://deploy-preview-14386--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against f796712

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[LukasTy]

Nice work! 💙
Sorry for a delayed review. 🙈

Does it fix #11016? 🤔

[Janpot]

Does it fix #11016? 🤔

it should yes, though I didn't explicitly try it yet.

[Janpot]

@LukasTy For that we will also need to point its dependencies to the core v7 packages. Will see if I can do that in #16563 next week

[alexfauquette]

@Janpot This PR seems to cause issues to resolve the @mui/x-charts

I started a reac-router project, and followed the charts installation guidelines. And moving the charts version from v8.0.0-alpha.11 to v8.0.0-alpha.12 makes if fail with the following error

Directory import '/home/alexandre/dev/mui/test-charts/node_modules/@mui/material/styles' is not supported resolving ES modules imported from /home/alexandre/dev/mui/test-charts/node_modules/@mui/x-charts/esm/PieChart/PieChart.js
Did you mean to import "@mui/material/node/styles/index.js"?

T make it work, I needed to update the material version to v7.0.0-beta.1

https://github.com/alexfauquette/test-charts

[LukasTy]

@alexfauquette I think that is the idea; you need to update both @mui/material as well as @mui/x-charts to an ESM compliant version.
AFAIK, @mui/[email protected] should be enough. 🤔

[alexfauquette]

Is there a workaround documented somewhere about how to use material v6?

[LukasTy]

Is there a workaround documented somewhere about how to use material v6?

Oh, shoot, sorry for missing the fact that after the change you can no longer use older @mui/material version. 🙈
I assume that if it worked before, it should work with the latest version as well. 👍
Otherwise, this needs attention, as he peer dependencies no longer make sense...

[Janpot]

Is there a workaround documented somewhere about how to use material v6?

As I understood, v6 doesn't work with react-router as per mui/material-ui#45281 and other issues. So nothing should be broken that wasn't broken before. There is no workaround, under Node.js ESM the strictest resolution rules apply. Perhaps something is possible with resolve.alias (bit like mui/material-ui#35233 (comment) but different), but really users should just upgrade to Material UI v7, it should be a light migration.

[Janpot]

@alexfauquette I can make it run when adding

// ./vite.config.ts
  ssr: {
    noExternal: [/^@mui\//],
  },

Looks like it could be a valid workaround, but I didn't extensively test this.

[cherniavskii]

Dropping @mui/material < 7 support is a pretty bad option for MUI X because this effectively forces users to upgrade to @mui/material if they want to benefit from the new features MUI X has released 🫠
@Janpot Are there other options for MUI X to consider? For example, reverting this PR? Would that allow MUI X to support @mui/material v6 and v7?

[Janpot]

@cherniavskii It seems to only be broken for native Node.js ESM module resolution. It looks like bundlers can digest the X@8, core@6 combo fine. e.g. Next.js. The main runtime affected so far seems to be vite with ssr (maybe some testing setups?). This is a relatively narrow use case, and vite is exactly the runtime you want to prioritize moving to Core@7 because Core@6 is utterly broken on vite, it's the reason why we're focussing so much on package layout this release. For vite users who still have good reasons to stay on Core@6, but must use X@8, we have a workaround which comes down to just "don't use native Node.js ESM, just bundle the @mui packages".

Reverting in #16871

[LukasTy]

I agree with Jan on this one. 🤔
I think that the rare issues on some setups is an understandable "price to pay" for a brighter future and easier transition to ESM in the longer run. 👍
I don't think that any library had a 100% smooth transition without certain edge cases. 🤔
If you ask me, I would vote to not revert the change and go with Jan's proposal.

[Janpot]

I'm not necessarily against reverting, I understand we want to offer predictability. In any case, I wouldn't go for it if the X team is not fully behind as well. My main reservation would be, are we optimizing for the right user? i.e. do we know about any users that have good reasons not to upgrade core to 7, but must absolutely move X to 8? I have seen a few requests of users that want to move core to 7 and are asking for when the change comes to X as well.

Maybe we should verify it on a few more platforms and see if we can come up with a workaround for each failing one.

I'm thinking:

• vite + ssr (workaround in this thread)
• just vite (should work)
• Next.js app router (seems to work)
• Next.js pages router ?
• vitest ?
• jest ?
• mocha ?
• ?

For anything vite, they will potentially run in any of the bugs listed in mui/material-ui#43938

[cherniavskii]

It looks like bundlers can digest the X@8, core@6 combo fine. e.g. Next.js.

Yes, it seems to work with the app router. Doesn't work with pages router though: https://stackblitz.com/edit/github-va8ctzeg-t6manklw?file=src%2Fpages%2Findex.js
Any ideas for workarounds?