[icons] Add exports field to package.json

[Janpot]

Currently esm requests for subpath module specifiers always resolve to the commonjs file. This PR adds an exports field to the package.json to correct the import. We don't change package layout, so anyone using a bundler that doesn't support the exports field should be unaffected.

Adding backwards compatible exports for specific setups we recommended in the past:

• https://mui.com/material-ui/guides/minimizing-bundle-size/#option-two-use-a-babel-plugin => https://github.com/avocadowastaken/babel-plugin-direct-import?tab=readme-ov-file#example
  Solving this by adding ./esm conditions.

  "./esm/*": "./esm/*.js",
  "./esm/*.js": "./esm/*.js",

• Users following this advice [ESM] @mui/icons-material move to pure ESM #35233 (comment)

Closes #35233

Verified that it fixes the reproduction of #35233 (comment)

May also fully or partly fix:

• Popper.js:9 Uncaught TypeError: styled_default is not a function #32727
• Uncaught TypeError: styled_default is not a function #36511
• Issues with esbuild #31835
• Popper.js:11 Uncaught TypeError: styled_default is not a function at Popper.js:11:20 #36515

In the Next major version we can consider following changes:

• Remove ./esm/* and ./esm/*.js exports
• Remove commonjs (18.7MB => 6.1MB) [icons] Only ship ES modules #26310 [icons] Not able to install icons yarn add @material-ui/icons package #26240
• Remove support for top-level import ., it's a footgun, we could just disallow importing from it altogether. It would reduce package size as well to be able to remove the barrel file. (minus 2.3MB)
• Add a negative export for ./utils

  "./utils/*": null,

• Use a single type declaration file for all icons instead of one for each icon. This could also reduce install size.

Opened a ticket here: #43629

[mui-bot]

Netlify deploy preview

https://deploy-preview-43624--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 05b31b2

[oliviertassinari]

In the Next major version we can consider following changes:

Should we open an issue for those? Add the "breaking change" label, so in the next major, we can easily review those.

[DiegoAndai]

@Janpot, it seems like you've covered all bases regarding the risks of releasing this in a minor version 🙌🏼 , so I'm on board with releasing it 👌🏼.

Just to make sure, did you test that we won't encounter the same issue that made us revert #26656 in the past? Do our tests cover this case now?

Finally, what do you think about waiting a couple of weeks before releasing this? Right now we're receiving a lot of feedback from the v6 stable, so I'm thinking we could hold this until the end of September. This way we avoid overloading the team in case we need to guide people through this change. Does this make sense to you?

[Janpot]

Just to make sure, did you test that we won't encounter the #26310 (comment) that made us revert #26656 in the past?

That PR changed the icons package to an ESM-only package which wasn't supported at the time by Next.js. This PR doesn't remove commonjs from the package, even though Next.js now supports ESM-only packages. I've smoke tested this PR against latest stable Next.js and I didn't see problems. The node conditional specifically instructs to use commonjs on the server.

Do our tests cover this case now?

We have some manual bundling tests to test module resolution, but it looks like they're broken. Will look into them when I can.

Finally, what do you think about waiting a couple of weeks before releasing this? Right now we're receiving a lot of feedback from the v6 stable, so I'm thinking we could hold this until the end of September. This way we avoid overloading the team in case we need to guide people through this change. Does this make sense to you?

It's up to the team. I'm happy to do it either way.

[brijeshb42]

Why has this been added? For backward compatibility ?

[Janpot]

Exactly, someone might have added

  resolve: {
    alias: [
      {
        find: /^@mui\/icons-material\/(.*)/,
        replacement: '@mui/icons-material/esm/$1',
      },
    ],
  },

to their vite config. It means under the hood their bundler is changing @mui/icons-material/Add to @mui/icons-material/esm/Add before the package.json resolution algorithm has even kicked in. If we don't add an export for this, that module request will follow the ./* => ./esm/*.js export and try to access ./esm/esm/Add.js (* == esm/Add). When we add this export, we special case the ./esm path to not add an extra esm segment (* == Add). We can remove this in a major version.

Same problem for users of https://github.com/avocadowastaken/babel-plugin-direct-import?tab=readme-ov-file#example

edit: you can test this with the pigment vite app. removing the export and putting back the vite config should break its build

[DiegoAndai]

🚀

[Janpot]

I'm removing the node condition again. It's currently erroring when importing natively as ESM on Node.js. We can keep this unsupported until we have true ESM files (v7).