-
Notifications
You must be signed in to change notification settings - Fork 183
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
Changes in Tailwind CSS v4 #919
Comments
Personally I "just" want to use Tailwind in my Nuxt project. Since v4 has first class Vite support, I question if a Nuxt module is still needed or what benefits it would have. I was happy when Nuxt Tailwind provided reloading when changing something in the tailwind.config.ts but apparently this is no more needed. I use Nuxt layers but I guess this doesnt affect Tailwind. I only barely use the devtools but if, I never used them for anything Tailwind related. What is really annoying is that every use of dynamic classes is not catched by Tailwind atm. At the beginning the behavior seemed buggy to me because styles were working and then suddenly not anymore and I couldnt figure out why. After figuring out and understanding the problem the only solution then is to put the classes in the safelist. But I guess there is nothing Nuxt Tailwind could do? |
I don't heavily rely on it but being able to use |
Same here, "just" want to use Tailwind v4 because of Nuxt UI v3. |
I tried Nuxt UI 3 with Tailwind 4 a lot already. As far as I see they dont use Nuxt/Tailwind. Works like a charm, I dont know if there is a need for a Nuxt Tailwind module anymore? |
Hi everyone,
I'm creating this issue to get an idea from the users of this module about certain changes and features in Tailwind CSS v4 that they'd like this module to integrate with.
If you haven't already, do give a read to the v4 prerelease documentation that covers all the changes:
https://tailwindcss.com/docs/v4-beta
I mention in #790 that this module mostly aims at installing and configuring Tailwind to your Nuxt project a breeze, and with this new version, Tailwind CSS has made it even easier; still, there are minor steps like configuring Vite within Nuxt (or webpack/other builders using PostCSS), setting up CSS, merging all the Nuxt layers, etc -- this is where the module would still be required.
There are a few more things that have changed in Tailwind CSS v4 that heavily influence on the approach for the next version of this module; I'm hoping to get comments on these functionalities (and more general bits I may have missed).
Configuration
Previously Tailwind required us to create a
tailwind.config.js
to enable minimum installation; this configuration file also helps in using plugins, safelists, and extending theme. This is no longer necessary, you can use v4 without a configuration file.How would you configure the theme?
The idea of Tailwind v4 is that it will be more
tailwind.css
configuration focused, thantailwind.config.cjs
(based on my understanding from this video). So, you have the@theme
directive. Read more about this here - https://tailwindcss.com/docs/v4-beta#customizing-your-themeWith that said, any (existing) configuration files can still be used in v4 - https://tailwindcss.com/docs/v4-beta#using-legacy-configuration-files - but it will not be highly configurable through this approach (also note the usage of word "legacy").
Content Configuration
When creating a
tailwind.config
file, you were required to specify resolvable paths to your source code in thecontent
property. This module also did that for you, so it wasn't necessary. However, projects have different natures of organising source code. Moreover, a file may exist in the tracker but not in the app lifecycle/tree; the class utilities from that file would still contribute to the final CSS.Tailwind v4 now looks at the module graph and detects utilities accordingly. Still, paths can be configured explicitly; read https://tailwindcss.com/docs/v4-beta#configuring-source-detection.
Exposed CSS variables
There was a little section in Tailwind v3 docs about referencing (configuration) in JavaScript. Here again this module provided an
exposeConfig
feature 👼 that would provide tree-shakable, typed values to your configurations.Tailwind v4 is based on CSS variables now, and the
resolveConfig
function is not exported anymore. https://tailwindcss.com/docs/v4-beta#referencing-theme-values-in-jsGiven some of the changes pointed above, I'm trying to brainstorm on where we go next. It may be possible to maintain the current usage of the module to work with v4, but it may not enable its best potential. We can also change into a
tailwind.css
based module (have the module generate it and automatically integrate) which seems like a nice idea. We could just be a simple Vite/PostCSS plugin installer too 😄So here's what I'm hoping to hear from you:
@theme
,@plugin
, etc. directives?exposeConfig
to use CSS variables), or possibly still have those abilities (that may not be as-usable at their best potential)?Let me know what you all think. I'm excited to take this new exciting route that hopefully everyone can enjoy!
The text was updated successfully, but these errors were encountered: