Mantine Component Library / dev mode / Error when evaluating SSR module #421
Comments
|
Thanks for reporting. Can anyone investigate it? It seems the error is different from others. |
|
To confirm, does |
Yes - The problem exists only in |
aheissenberger
changed the title
|
Oh, I misread the description. If it's CJS compatibility, it's a known limitation #110 and the workaround is something like this. waku/examples/12_css/vite.config.ts Lines 6 to 10 in 2742c3a |
|
Thanks - this fixed it - if you tell me where in the docs I can write a short text to help others:
import { defineConfig } from 'vite';
export default defineConfig(({ mode }) => ({
...(mode === 'development' && {
ssr: {
external: ['@mantine/core'],
},
}),
})); |
|
Great to hear. For now, how about |
|
I still have a Problem with all Components using the MantineProvider. They all have This is the wrapper component: repo to reproduce the problem: https://github.com/aheissenberger/waku-mantine-broken
|
|
Update on my tests:
@dai-shi Please give me some advice where I can further investigate to fix this problem. It looks like it is related to the SSR done with |
|
@dai-shi I need help - I have debugged this multiple times and still do not understand why the context ist lost. Here is a repository which only tries to access the Mantine Theme Context and always fails. The repo to reproduce the problem: This is the Mantine Context Provider which fails: |
|
Hi, sorry for the delay. Confirmed the use client directive: https://unpkg.com/browse/@mantine/[email protected]/esm/core/MantineProvider/MantineProvider.mjs So, I think we need to sit down and investigate it deeply.
Oh, you already tried it. Then, I'd add Mantine code into your own Context one by one, until it reproduces the error. |
Render StaticcreatePage({
render: 'static',
path: '/mantine',
component: MantinePage,
});Error: @mantine/core: MantineProvider was not found in component tree exists:
Works
Error build with SSR Render Dynamic createPage({
render: 'dynamic',
path: '/mantine',
component: MantinePage,
});Error: @mantine/core: MantineProvider was not found in component tree exists:
Works:
Error start with SSR |
|
add I was able to debug and isolate the Problem - it is related to the library // react-textarea-autosize.browser.esm.js
// line 104
var isIE = !!document.documentElement.currentStyle ;The problem is that You can reproduce the problem with: create a page with: import { MantineProvider } from '@mantine/core';
import { Textarea } from '@mantine/core';
export const TextareaPage = async () => {
return (
<div>
<title>TextAreaPage</title>
<h1>TextAreaPage</h1>
<MantineProvider>
<Textarea autosize={true}/>
</MantineProvider>
</div>
);
};run some more curiositiesThis will build textinput-page.tsx: import { MantineProvider } from '@mantine/core';
import { TextInput} from '@mantine/core'
export const TextinputPage = async () => {
return (
<div>
<title> TextinputPage </title>
<h1> TextinputPage </h1>
<MantineProvider>
<TextInput />
</MantineProvider>
</div>
);
};If I extract the TextInputComponent.tsx: 'use client'
import { TextInput} from '@mantine/core'
export const TextInputComponent = () => {
return (<div><TextInput/></div>);
}textinput-page.tsx: import { MantineProvider } from '@mantine/core';
import { TextInputComponent } from '../components/TextInputComponent.js';
export const TextinputPage = async () => {
return (
<div>
<title> TextinputPage </title>
<h1> TextinputPage </h1>
<MantineProvider>
<TextInputComponent />
</MantineProvider>
</div>
);
}; |
I wonder how Waku imports https://unpkg.com/browse/[email protected]/package.json "worker" isn't listed in https://runtime-keys.proposal.wintercg.org/ nor in https://github.com/browserslist/browserslist#browsers, and I'm not sure if it means "webworker" or "cloudflare workers". We should probably avoid it. Related #393 by @himself65 |
That's interesting and nice finding for a hint. |
|
I can do that in the next few days! |
I am not an expert on Some how the condition "exports": {
".": {
"types": {
"import": "./dist/react-textarea-autosize.cjs.mjs",
"default": "./dist/react-textarea-autosize.cjs.js"
},
"development": {...},
"worker": {
"module": "./dist/react-textarea-autosize.worker.esm.js",
"import": "./dist/react-textarea-autosize.worker.cjs.mjs",
"default": "./dist/react-textarea-autosize.worker.cjs.js"
},
"browser": {
"module": "./dist/react-textarea-autosize.browser.esm.js",
"import": "./dist/react-textarea-autosize.browser.cjs.mjs",
"default": "./dist/react-textarea-autosize.browser.cjs.js"
},
"module": "./dist/react-textarea-autosize.esm.js",
"import": "./dist/react-textarea-autosize.cjs.mjs",
"default": "./dist/react-textarea-autosize.cjs.js"
},
"./package.json": "./package.json"
}, |
|
@dai-shi what I do not understand is why the rendering (SSR on server during build) export function loadModule(id) {
switch (id) {
case 'rsdw-server':
return import('./rsdw-server.js');
case 'client/react':
return import('./public/assets/react.js');
case 'client/rd-server':
return import('./public/assets/rd-server.js');
case 'client/rsdw-client':
return import('./public/assets/rsdw-client.js');
case 'client/waku-client':
return import('./public/assets/waku-client.js');
case 'public/assets/waku-client.js':
return import('./public/assets/waku-client.js');
case 'public/assets/rsc0-47a606723.js':
return import('./public/assets/rsc0-47a606723.js');
...This is the reason for the |
|
SSR is basically traditional client React rather than RSC. So, it runs with client bundles. Otherwise, we can't render client components on server. I'm not sure if this answers to your question all. Feel free to have follow-up questions. |
Yeah, I think removing the "browser" condition will solve this. But, not sure if it breaks other cases as a side effect. |
I think you will need to bundle a different set of modules for SSR at build time without the condition "browser". The existing modules in the
|
|
"worker" condition looks like an undocumented name. There are two kinds of workers: node worker and web worker, and maybe more: deno worker... anyway they are all just |
In my option - see above - the bundle conditions required for SSR during the build step can leave it to the package.json import configuration to choose the right package. As long as there is no "browser" condition, the default in the import section of packages.json is pointing to a version of the code which does not need a browser environment. |
I'm a bit skeptical about it. Our implementation shouldn't be that complicated, and it basically leads to more "hydration mismatch" errors. Can anyone investigate how Next.js solves it? |
I have no idea how Next.js works but I use Solid Start which uses vinxi from @nksaraf. The internal output folder I did some research based on the official Vite SSR & SSG Example code and my findings are:
Here is my repro which I used to conduct the tests: I suggest to change the build pipeline to support the following target output:
maybe have a look at vinxi - specifically the existing deploy adapter from the Nuxt ecosystems Nitro Stack are amazing. |
|
Okay, if we were to split bundles to three types, it would require re-architecture to some extent and might be able to only come after v0.20. There's an issue with Vite, as I see, because we use Vite's SSR mode for RSC, it's conflicting. We could work it around with two vite configs, but I wish Vite would support RSC (a new server mode) natively. Otherwise, our code base won't be fairly maintainable. That said, I'm not sure if I understand the issue and the community standard (especially Meanwhile, I would like to try two workarounds:
|
|
SOLVED IT! FINALLY. Just when this entire thing seemed impossible to understand and I was about to give up... Here's the required config, I will post an explanation of my findings later:
Also note that you don't have to put this on your package.json. You can instead add the
Mantine should work fine in dev mode now |
|
So, it's basically this is the trick? I think noExternal is already applied. optimizeDeps: {
exclude: ["@mantine/core", "@mantine/hooks"]
}, |
I'll check again tomorrow (not on my computer), but I don't think First I added mantine to But still the app would then immediately crash clientside (from the same error) during hydration. It looks like optimizeDeps exclude fixed this So yeah, it's strange - looks like ssr noExternal tells vite "fix this package on the server" & optimizeDeps exclude tells vite "fix this on the client" |
|
Follow up: I'm happy I managed to fix this for my own use-case but I think it's far more important we use this opportunity to nail down what the root cause is. Before & After Comparison "Broken" setup vite.config.ts Contents of
Working setup vite.config.ts Contents of
Observations & open questions
This is observed by adding The answer to this is adding
|
|
@Aslemammad Can you help here? @jkhaui btw, there's |
…hi#779) Hmm, this is going to be a big problem with ESM/CJS compat... Maybe related: dai-shi#421, dai-shi#428
|
@jkhaui great work finding a working setup - but did you find a solution to bundle the matine packages? |
|
still breaks with |
|
Hmm. Can you update the repro with the latest |
Sorry I didn't see this (started a new job so have limited time to experiment with waku atm Hmm yeah you're right. I never investigated deeper as I didn't experience any noticeable perf issues, but this explains why there's like 150 tiny RSC chunks in the build output! Hopefully I can help look into this soon. I've been comparing Waku's build pipeline with Astro + react 19. I find it odd that there doesn't appear to be significant difference between how either framework uses vite in the build process. However, Waku has a lot more trouble bundling certain libs. My guess is that the need for a separate environment to bundle RSCs might be the reason |
I always test with the lastest commits in |
|
Okay. I mean if I can test your repo. https://github.com/aheissenberger/waku-mantine-broken isn't updated. |
|
You can find a test in the examples/xx_mantine in the branch "mantine-test" of my forked repo of WAKU: |
|
Thanks. You are not using the latest version. It has to be the same waku version in package json or use the workspace protocol. Here's the fix: diff --git a/examples/xx_mantine/package.json b/examples/xx_mantine/package.json
index 8f01461d..24033eff 100644
--- a/examples/xx_mantine/package.json
+++ b/examples/xx_mantine/package.json
@@ -16,10 +16,10 @@
"@mantine/dates": "^7.12.1",
"@mantine/hooks": "^7.12.1",
"dayjs": "^1.11.12",
- "react": "19.0.0-rc.0",
- "react-dom": "19.0.0-rc.0",
- "react-server-dom-webpack": "19.0.0-rc.0",
- "waku": "0.21.0-beta.0"
+ "react": "19.0.0-rc-68dbd84b-20240812",
+ "react-dom": "19.0.0-rc-68dbd84b-20240812",
+ "react-server-dom-webpack": "19.0.0-rc-68dbd84b-20240812",
+ "waku": "0.21.0-beta.5"
},
"devDependencies": {
"@types/react": "18.3.3",
diff --git a/examples/xx_mantine/src/pages/_layout.tsx b/examples/xx_mantine/src/pages/_layout.tsx
index a3bb4224..a5686f6f 100644
--- a/examples/xx_mantine/src/pages/_layout.tsx
+++ b/examples/xx_mantine/src/pages/_layout.tsx
@@ -3,7 +3,7 @@ import '@mantine/core/styles.css';
import type { ReactNode } from 'react';
import { MantineProvider } from '@mantine/core';
-import {theme} from '../theme';
+import { theme } from '../theme';
type RootLayoutProps = { children: ReactNode };
@@ -11,10 +11,14 @@ export default async function RootLayout({ children }: RootLayoutProps) {
const data = await getData();
return (
- <MantineProvider theme={theme} withNormalizeCSS>
- {children}
- </MantineProvider>
-
+ <html>
+ <head></head>
+ <body>
+ <MantineProvider theme={theme} withNormalizeCSS>
+ {children}
+ </MantineProvider>
+ </body>
+ </html>
);
} |
|
@dai-shi sorry for using an older version, but this did not fix the error I get with |
|
Treeshaking is not working and all files from Mantine Library are loaded in the browser on each page (143 requests): 
|
|
As for dev error, please try this: diff --git a/examples/xx_mantine/vite.config.ts b/examples/xx_mantine/vite.confi
g.ts
index 39325f79..a94ea43a 100644
--- a/examples/xx_mantine/vite.config.ts
+++ b/examples/xx_mantine/vite.config.ts
@@ -1,8 +1,9 @@
export default {
optimizeDeps: {
- exclude: ["@mantine/core", "@mantine/hooks","@mantine/dates","dayjs"]
+ include: ["dayjs", "dayjs/plugin/*"],
+ exclude: ["@mantine/core", "@mantine/hooks","@mantine/dates"]
},
ssr: {
- noExternal: ["@mantine/core", "@mantine/hooks","@mantine/dates","dayjs"],
+ noExternal: ["@mantine/core", "@mantine/hooks","@mantine/dates"],
}
}; |
|
I'm not sure about treeshaking not working in PRD. |
|
@dai-shi I update the configuration and tested all other Mantine Libraries and documented the setup or problems in the README.md of my repo The Mantine Main Libraries including Dates, Forms and most of the Extentions are working with release There are Problems with:
|
|
That's weird. This seems to improve it. diff --git a/examples/xx_mantine/vite.config.ts b/examples/xx_mantine/vite.config.ts
index 7440ddf4..8cd43cfa 100644
--- a/examples/xx_mantine/vite.config.ts
+++ b/examples/xx_mantine/vite.config.ts
@@ -10,10 +10,4 @@ export default {
"@mantine/notifications > prop-types",
]
},
- ssr: {
- noExternal: ["@mantine/core", "@mantine/hooks", "@mantine/dates", "@mantine/charts",
- "@mantine/code-highlight", "@mantine/notifications", "@mantine/spotlight",
- "@mantine/carousel",
- "@mantine/dropzone", "@mantine/nprogress", "@mantine/modals", "@mantine/tiptap"],
- }
};What are the remaining problems? (Apart from "tree-shaking not working". Hm, it might be because of prefetching, not related with tree-shaking.) |
|
@aheissenberger I just thought to try something which is adding the following to This change alone dropped no. of network requests in my minimal app from 144 -> 132. Maybe you can investigate this to see if it also treeshakes more unused code (I don't have much spare time atm) It had always been on my mind to try this, but initially I thought it didn't work because I got a broken app setting |
|
Updated Example which supports the current WAKU release is here:
|
|
Is the remaining issue this #421 (comment) ? |
The problem with the not optimized core package can be solved with this in export default {
build: {
chunkSizeWarningLimit: 1000,
rollupOptions: {
output: {
manualChunks(id) {
if (id.includes("@mantine/core")) {
return "@mantine/core";
}
},
},
},
},
};The packages which are still broken are:
I have documented my status here: |
Ah, then my misunderstanding was incorrect. Great you found a workaround. |
Thanks for the summary. Can anyone help on this?? |
How can I use Mantine with WAKU without getting this Error:
(
waku dev --with-ssrorwaku dev- no problem withwaku build --with-ssr)repo to replicate the error: https://github.com/aheissenberger/waku-mantine-broken
Versions:
Mantine: 7.4.2 - works with NextJS App Router and has
'use client'in all components - https://mantine.dev/guides/next/WAKU: 0.19.1
root-layout.tsx
The text was updated successfully, but these errors were encountered: