-
-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MUI React Component Library / Fails in all modes #428
Comments
|
@Aslemammad any insight? |
I'll take a look at this! |
looks like commonjs plugin run twice? |
no improvement here with #457 |
taking a look on this. |
I'm getting a different error:
|
With the current main branch and the
This is the error - when using DEV MODE The error |
Yes, I'm trying to fix it! Hope I get the answer to the issue soon. |
Well, the dev issue is because emotion/mui are not supporting RSC properly. emotion-js/emotion#2928 Let me see the build error now. |
The reason for the build error, in many mui modules is that commonjs resolver in rollup seems to have an issue with
I could not find a solution, it'd be interesting to have this reproduced in a vite template without waku or any other module. I feel I put so much time on finding the answer, but could not, so it might be better to take a time off and put time on the other issues. |
So, is it MUI issue?
okay. |
Yes, that's how I see it. I might be wrong though. |
@aheissenberger Your thought? |
Currently busy with other projects but I will give it some time and check how it works outside Waku and with NextJS App folder. I won't start before mid of next week. |
What's the issue with Material UI? |
I will test it against the current version today and will report the progress. |
@oliviertassinari MUI 5.15.15 and 6.0.0-alpha.2 are not working with WAKU 0.20.1-alpha.0 in SSR mode. |
I mean, what's the root cause? Reading the thread, it seems to be about the way Material UI implements ESM/CJS dual mode support. |
Yes, a "modern" react library needs to provide code for three different environments during bundling:
Second, MUI and Mantine use a React Context for theming which is not supported on the backend. MUI provides a fix for this with a special RSC Cache for Next.js. Look at react-textarea-autosize library to see how they bundle and setup the package.json export section to support all modes. I know MUI 5.15 works with next.js 14 but many library do some kind of rsc/webpack detection which only works with next.js :-(. |
I'm investigating these issues in @lazarv/react-server and my results might help you out here too as it's possible that some workarounds work with Waku too. When I import a MUI component as default, I get a React error about the imported component: import Button from "@mui/material/Button";
export default function App() {
return <Button variant="contained">Hello world</Button>;
}
This is because the
When I'm importing the Button component from the main @mui/material module, it works! import { Button } from "@mui/material";
export default function App() {
return <Button variant="contained">Hello world</Button>;
} Surely this is not ideal, but at least works even with SSR. Based on this finding someone might have a solution for this for the import to work properly, but it seems like some issue with Vite and Material UI, maybe some exports and conditions issue on Material UI's side. I also tried this out using my |
Thanks! It seems like we should create a minimal repro again after Waku v0.21 is out. I think I might have a better understanding of the problem and possible solution. |
I checked with Waku "main" (aa8b021) and MUI "6.0.0-alpha.12". There is a problem with "waku dev" mode. // _layout.tsx
import type { ReactNode } from 'react';
import { ThemeProvider } from '@mui/material/styles';
import CssBaseline from '@mui/material/CssBaseline';
import theme from '../theme.js';
import Button from '@mui/material/Button';
type RootLayoutProps = { children: ReactNode };
export default async function RootLayout({ children }: RootLayoutProps) {
const data = await getData();
return (
<ThemeProvider theme={theme}>
{/* CssBaseline kickstart an elegant, consistent, and simple baseline to build upon. */}
<CssBaseline />
<Button
variant='contained'
>
DEMO
</Button>
</ThemeProvider>
);
} Using MUI without a
|
I'm working on #709 and it may or may not change something for MUI. |
Version: WAKU "0.21.0-beta.0" (Commit 06122aa) Different Error with
|
If I understand it correctly, adding this in vite.config.ts might help: export default {
ssr: {
optimizeDeps: {
include: ['...'],
},
},
}; |
I added |
ok, my understanding was incorrect. @Aslemammad when you have time, can you have a look? |
…hi#779) Hmm, this is going to be a big problem with ESM/CJS compat... Maybe related: dai-shi#421, dai-shi#428
Could anyone try the latest version and summarize the issue as of now? |
Thanks for the small reproduction! Yeah, there seems to be a bug somewhere. |
For the first case, if I disable "ssr", // vite.config.ts
export default {
optimizeDeps: {
include: [
"@mui/utils",
"prop-types",
"hoist-non-react-statics",
"react-is",
],
},
}; Still investigating with the "ssr" usage. |
Did some more investigation with "ssr".
I added
So, I added this to "exports": {
".": {
"import": "./esm/index.js",
"default": "./index.js"
},
"./*": {
"import": "./esm/*/index.js",
"default": "./*/index.js"
}
}, Now, I get the same error for This seems like an endless game. Only the solution from our end would be to avoid using In the meantime, this small reproduction works flawlessly with PRD ( |
pnpm waku dev
orpnpm waku dev --with-ssr
- looks like a problem in ViteJS:Repo to reproduce error:
https://github.com/aheissenberger/waku-mui
Error:
ppm waku build
Error:
The text was updated successfully, but these errors were encountered: