Reproduction URL (Required)
https://github.com/joefefs/daisyui-vite-8-test
What version of daisyUI are you using?
v5.5.19
Which browsers are you seeing the problem on?
Chrome
Describe your issue
When customizing a built-in theme using @plugin "daisyui/theme" as documented, the custom color values are overridden by daisyUI's built-in theme colors in the final build.
Environment:
• daisyUI 5.5.19
• Tailwind CSS 4.2.2
• Vite 8.0.x
Steps to reproduce
Clone the minimal repo with the reproduction in this bug report, and cd into it.
-
Run npm install
-
Run npm run build
-
Once built, run:
npx vite preview this will effectively run the production build. Go to http://localhost:4173/
-
Notice in the style.css file how the primary color is set to red and the secondary color to blue for both light and dark themes.
-
In the UI, click the "toggle" button to switch to dark and then back to light mode. Notice how the light theme is now defaulting the styles to DaisyUI's built-in theme, instead of the custom one.
A couple of observations:
- Using
default: true; in one of the theme color declaration will cause this issue for that particular theme. Initially the theme will be rendered with the correct colors, but after the toggle, the one with the default will fallback to DaisyUI built-in theme.
- Removing
default: true; from both dark and light themes, will cause the initial load to show DaisyUI built-in theme instead of the custom one, but after toggle both themes will show render the proper theme.
Root Cause
Vite 8 defaults to LightningCSS for minifying the CSS in production builds. The minifying via LightningCSS is causing the issue, and only affects production builds. Explicitly changing the minifier to esbuild or disabling it all will get rid of the issue.
Workarounds
There's 2 possible workarounds (other than downgrading Vite to v7):
- Add
build: { cssMinify: false } to vite.config.js, which is unideal for production
- Add
build: { cssMinify: 'esbuild' } which requires to manually install esbuild as Vite 8 no longer installs this dependancy.
Both of this workarounds will work on the reproduction example.
Reproduction URL (Required)
https://github.com/joefefs/daisyui-vite-8-test
What version of daisyUI are you using?
v5.5.19
Which browsers are you seeing the problem on?
Chrome
Describe your issue
When customizing a built-in theme using @plugin "daisyui/theme" as documented, the custom color values are overridden by daisyUI's built-in theme colors in the final build.
Environment:
• daisyUI 5.5.19
• Tailwind CSS 4.2.2
• Vite 8.0.x
Steps to reproduce
Clone the minimal repo with the reproduction in this bug report, and
cdinto it.Run
npm installRun
npm run buildOnce built, run:
npx vite previewthis will effectively run the production build. Go to http://localhost:4173/Notice in the
style.cssfile how the primary color is set toredand the secondary color tobluefor both light and dark themes.In the UI, click the "toggle" button to switch to dark and then back to light mode. Notice how the light theme is now defaulting the styles to DaisyUI's built-in theme, instead of the custom one.
A couple of observations:
default: true;in one of the theme color declaration will cause this issue for that particular theme. Initially the theme will be rendered with the correct colors, but after the toggle, the one with the default will fallback to DaisyUI built-in theme.default: true;from both dark and light themes, will cause the initial load to show DaisyUI built-in theme instead of the custom one, but after toggle both themes will show render the proper theme.Root Cause
Vite 8 defaults to LightningCSS for minifying the CSS in production builds. The minifying via LightningCSS is causing the issue, and only affects production builds. Explicitly changing the minifier to
esbuildor disabling it all will get rid of the issue.Workarounds
There's 2 possible workarounds (other than downgrading Vite to v7):
build: { cssMinify: false }tovite.config.js, which is unideal for productionbuild: { cssMinify: 'esbuild' }which requires to manually installesbuildas Vite 8 no longer installs this dependancy.Both of this workarounds will work on the reproduction example.