When using the latest version of MUI in Astro, it prompts that "require is not defined"

[cpxGithub]

Steps to reproduce

Link to live example: (required) https://stackblitz.com/edit/github-habvmy?file=src%2Fcomponents%2FCounter.tsx

Steps:
1.Create an Astro React project via pnpm create astro@latest --template framework-react
2.Use the command pnpm add @mui/material @emotion/react @emotion/styled to install MUI
3.Add Button component in Counter.tsx file
4.Add the following configuration in the astro.config.mjs file

5.Run pnpm dev, and the following error message appears in the terminal.

6.Modify "@mui/material": "^5.15.21" to "@mui/material": "5.14.20" to run normally

Current behavior

Expected behavior

No response

Context

No response

Your environment

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
  System:
    OS: macOS 14.2
  Binaries:
    Node: 22.2.0 - /opt/homebrew/bin/node
    npm: 10.7.0 - /opt/homebrew/bin/npm
    pnpm: 9.4.0 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 126.0.6478.127
    Edge: 126.0.2592.87
    Safari: 17.2
  npmPackages:
    @emotion/react: ^11.11.4 => 11.11.4 
    @emotion/styled: ^11.11.5 => 11.11.5 
    @mui/material: ^5.15.21 => 5.15.21 
    @types/react: ^18.3.3 => 18.3.3 
    react: ^18.3.1 => 18.3.1 
    react-dom: ^18.3.1 => 18.3.1 
    typescript: ^5.4.5 => 5.4.5 

Astro info

Astro                    v4.11.0
Node                     v22.2.0
System                   macOS (arm64)
Package Manager          npm
Output                   server
Adapter                  @astrojs/cloudflare
Integrations             @astrojs/react
                         astro-i18next

Search keywords: astro

[DiegoAndai]

Hey @cpxGithub, thanks for the report!

You mentioned that this worked on 5.14.20 but not 5.15.21. Do you know the specific version it stopped working on? This will be very helpful in identifying the issue.

[cpxGithub]

Version 5.15.11 stopped working

[DiegoAndai]

Might be related to this change: v5.15.10...v5.15.11#diff-9446ee1698c37d364b00d92c4ad52112e927a41211b65bd288d0ee193e3f14aaL55. As the noExternal regex will now also apply to the internal babel macros imports. I tried changing to noExternal: /@mui\/(?!(internal-babel-macros)).*?/ but that didn't work.

On the sandbox shared, I cannot make it work even with v5.14.20. I get:

@cpxGithub may I ask you to share a working example with v5.14.20?

[cpxGithub]

Sorry, it was my mistake. I added extra code to the example. Now I have fixed the example and set the version to 5.14.20. New example address: https://stackblitz.com/edit/github-habvmy-ftgbpk?file=package.json

[DiegoAndai]

@michaldudak may I ask for your help here?

The example works with 5.15.10 and stops working with 5.15.11. The commits for that release are here: v5.15.10...v5.15.11#diff-9446ee1698c37d364b00d92c4ad52112e927a41211b65bd288d0ee193e3f14aaL55

I see a couple of PRs that might be related:

• [code-infra] Prepare babel macros package for publishing to npm #41178
• [code-infra] Build internal packages before publishing #41210

But I wonder if those are the cause or not, or if there might be another suspicious change.

Related docs:

• https://vitejs.dev/config/ssr-options#ssr-noexternal (the project uses /@mui\/.*?/)
• https://vitejs.dev/guide/ssr#ssr-externals

[michaldudak]

Looking briefly at it, I doubt that it has anything to do with Babel macros. We use them only in development and they are not a part of the resulting bundle. I'll keep investigating it further.

[DiegoAndai]

Thanks for taking a look 👌🏼

If none of those two PRs are related, then I don't know which v5.15.11 change could be the cause.

require not being defined points to me that the file is, for some reason, read as a module instead of cjs. Is that correct?

[michaldudak]

The main difference between this project using 5.15.10 and 5.15.11 is in node_modules/.vite/deps/@mui_material.js.

Specifically, some of the imports come from the node_modules/@mui/system/ directory where before they came from node_modules/@mui/system/esm/.

The most suspicious change related to @mui/system is changing all the named root imports (import { colorManipulator } from "@mui/system") to default deeper ones (import colorManipulator from "@mui/system/colorManipulator"). Perhaps importing from a subpath forces the node version?

[DiegoAndai]

@michaldudak thanks fro looking into it, the explanation makes sense.

In v5, @mui/system has a different structure than the other packages, having CJS code in its root and ESM under /esm/. This was changed for v6: #41574. I think this change might've fixed the issue? I tested with 6.0.0-beta.2 and the example seems to be working. @cpxGithub may I ask that you try this and confirm if it also fixes the issue on your side?

[cpxGithub]

It works fine, but I found another problem, using @mui/icons-material in the project reported the same problem, even if I upgraded to the latest version (6.0.0-beta.4)

[DiegoAndai]

@cpxGithub, Sorry for the delay; this also seems like a CJS/ESM interoperability issue. You can fix it with this config:

export default defineConfig({
  output: 'server',
  integrations: [react()],
  vite: {
    resolve: {
      alias: {
        // alias icons to their ESM version
        '@mui/icons-material': '@mui/icons-material/esm',
      },
    },
    ssr: {
      noExternal: /@mui\/.*?/,
    },
  },
});

Here's the sandbox working: https://stackblitz.com/edit/github-habvmy-7bff2d?file=astro.config.mjs

This should no longer be necessary once #35233 is completed.

Does this solve your issue?

[github-actions]

Since the issue is missing key information and has been inactive for 7 days, it has been automatically closed. If you wish to see the issue reopened, please provide the missing information.