[v4] @apply inside Svelte / Vue <style> not working as expected

[lucas-subli]

What version of Tailwind CSS are you using?

tailwindcss: 4.0.0-beta.2
@tailwindcss/vite: 4.0.0-beta.2

What build tool (or framework if it abstracts the build tool) are you using?

svelte: 5.2.9
sveltekit: 2.8.5

What version of Node.js are you using?

v20.17.0

What browser are you using?

Chrome, Firefox

What operating system are you using?

Ubuntu 24.04

Reproduction URL

Public github:
https://github.com/lucas-subli/svelte-5-tailwind-4-beta

pnpm install
pnpm dev --open

Describe your issue

This code:

<h1 class="text-red-500">This is red</h1>
<h1 class="red">This should be red</h1>

<style>
  .red {
      @apply text-red-500;
  }
</style>

Generates this result:

With this error:

[plugin:vite-plugin-svelte] Error while preprocessing /home/lucas/Workspace/stuff/svelte-5-tailwind-4-beta/src/routes/+page.svelte - Cannot apply unknown utility class: text-red-500

@apply inside svelte <style> does not work properly.

After this PR: #14151
The below will work:

<style global>
  @import 'tailwindcss';

  .red {
      @apply text-red-500;
  }
</style>

However, flagging the style as global and importing 'tailwindcss' in every component I want to use @apply is not a reasonable solution.

The PR mentioned above also has a comment stating:

// In practice, it is not recommended to use `@tailwind utilities;` inside
// Svelte components. Use an external `.css` file instead.

However, this does not seem to work, as seen in the provided reproduction URL, where tailwind is imported by app.css and made available through +layout.svelte — as previously done with tailwind 3 + SvelteKit.

[adamwathan]

Hey! Check the relevant documentation here:

https://tailwindcss.com/docs/v4-beta#using-apply-in-vue-svelte

TL;DR:

<style>
  @import 'tailwindcss/theme' theme(reference);

  .red {
      @apply text-red-500;
  }
</style>

[lucas-subli]

Is that intended as the final solution?

Importing tailwindcss/theme in every component that needs to use @apply does not feel like a good user experience.

I think the gold standard would be for it to simply work - not sure if this is technically possible.

Failing that something similar to V3's lang would also be better. Maybe <style lang="tailwindcss">, but again not sure if this technically feasible.

[metroite]

See my answer here for a slightly better solution: #15205 (comment)

[amir20]

I also noticed this with Vue. It took me a long time to realize that I need @import "tailwindcss/theme" theme(reference);.

I agree that this doesn't feel intuitive. Adding @import everywhere seems like unnecessary syntactic sugar. Not to mention that currently in VSCode and Zed editors, this breaks syntax highlighting.

I hope to improve "quality of life" for v4. :P

[wlkns]

I'm also looking for a solution to this - I appreciate the preferred approach is to use inline classnames but I do end up using @apply across almost all components.... A solution for us few would be nice.

[ranseur92]

import type { Plugin } from 'vite'
function autoInjectTWTheme() {
  return {
    name: 'auto-inject-tailwind-theme',
    transform(src, id) {
      if (/\.vue$/.test(id)) {
        if (src.includes('<style')) {
          src = src.replace(/(<style ?.*?>)/g, `$1\n@import 'tailwindcss/theme' theme(reference);`)
        }
        return { code: src, map: null }
      }
    },
  } satisfies Plugin
}

Anybody wanting a temporary solution that you could in theory, forget about. I wrote this tiny plugin for vite, which auto-injects the required fix into all .vue files, so you don't have to do it manually.

Note: Place the plugin as the first 1.

Ignore the above, it doesn't work properly with HMR :(

[yy4382]

This is also required for Astro's <style is:global> blocks, maybe need to add this to the docs.

[vadimmelnicuk]

Just attempted to update to tailwind 4 & bumped into this issue when using it with Vue & Nuxt UI 4.
Any updates on this?

[adamwathan]

Here's the docs I wrote for this earlier this week that will be in the v4 docs, including the CSS modules docs since they go into more detail about the same stuff:

---

Vue, Svelte, and Astro

Vue, Svelte, and Astro support <style> blocks in component files that behave very much like CSS modules, which means they are each processed by your build tooling totally separately and have all of the same drawbacks.

If you're using Tailwind with these tools, we recommend avoiding <style> blocks in your components and just styling things with utility classes directly in your markup, the way Tailwind is meant to be used.

If you do use <style> blocks, make sure to import your global styles as reference if you want features like @apply to work as expected:

<template>
  <button><slot /></button>
</template>

<style scoped>
  @import "../app.css" reference;

  button {
    @apply bg-blue-500;
  }
</style>

Or just use your globally defined CSS variables instead of features like @apply, which don't require Tailwind to process your component CSS at all:

<template>
  <button><slot /></button>
</template>

<style scoped>
  button {
    background-color: var(--color-blue-500);
  }
</style>

CSS modules

Tailwind is compatible with CSS modules and can co-exist with them if you are introducing Tailwind into a project that already uses them, but we don't recommend using CSS modules and Tailwind together if you can avoid it.

Scoping concerns

CSS modules are designed to solve scoping problems that just don't exist when composing utility classes in your HTML instead of writing custom CSS.

Styles are naturally scoped with Tailwind because each utility class always does the same thing, no matter where it's used — there's no risk that adding a utility class to one part of your UI creates some unexpected side effect somewhere else.

Performance

When using CSS modules, build tools like Vite, Parcel, and Turbopack process each CSS module separately. That means if you have 50 CSS modules in a project, Tailwind needs to run 50 separate times, which leads to much slower build times and a worse developer experience.

Explicit context sharing

Since CSS modules are each processed separately, they have no @theme unless you import one.

This means features like @apply won't work the way you expect unless you explicitly import your global styles as reference:

@import "../app.css" reference;

button {
  @apply bg-blue-500;
}

Alternatively, you can also just use CSS variables instead of @apply which has the added benefit of letting Tailwind skip processing those files and will improve your build performance:

button {
  background: var(--color-blue-500);
}

---

I don't really consider this a workaround or anything, this is the API you need to use when you want to reference Tailwind theme variables from a totally disconnected entry point which is how these style blocks work.

Imagine you had two main CSS files in your project that looked like this:

/* admin.css */
@import "tailwindcss";

@theme {
  --color-primary: blue;
}

/* frontend.css */
@import "tailwindcss";

@theme {
  --color-primary: red;
}

Now in some Vue file you do this:

<template>
  <h1>Hello world</h1>
</template>

<style>
  h1 {
    @apply text-primary;
  }
</style>

There's no way to know if that is supposed to be blue or red without loading the relevant theme configuration. So just like in JS when you need to import something to use it, the same thing is true with v4.

[Stephan-MC]

I think this discussion makes tailwind v4 more clear in my head and more interesting 🤔. I’m impatiently waiting for the officially release. Sure it will come with lot of goodies 😋

[lucas-subli]

That is very good summary of the techinical issues at hand.

But it is still not clear to me that those technical decisions impede a better usability for the aforementionet frameworks. I will just intro on why this is so important and comment on each of your points:

Why is this so important

I will be selfish here and explain my use case as a proxy for the general problem

Previously this would work fine:

<script lang="ts">
	import type { ButtonProps } from './types';

	let {
		type = 'standard',
	}: {type: 'standard' | 'outline' | 'jumbotron' | 'text' } = $props();
</script>

<button
	class="{type}"
>
	{@render children()}
</button>

<style lang="postcss">
  .standard {
     @apply rounded border border-primary-500 bg-primary-500 hover:bg-primary-700 px-3 py-2 text-sm (...)
  }

  .outline {
     @apply rounded border border-primary-500 hover:bg-primary-500 px-3 py-2 text-sm (...)
  }

  .jumbotron {
      (...)
   }

  .text {
      (...)
   }

Now I either need to:

• Add an unintuitive import. I don't want to do that there are several things I don't like here. It violates several import rules in the linter for my particular project that I don't want to change. It is unintuitive and it will most likely cause issues long term with the devs just copying and pasting with no understanding of the reasoning.

• Remove @apply and use tailwind css vars. I have over 200+ components written like that, this would take me forever, and it is prone to error.

• Move this to inline tailwind classes: Since those are conditional to the button type which could have several value the cleanest way would be adding a getClasses() function or similar. I would be adding Javascript complexity without need making the code less obvious for new joiners on the project. This would also hinder the autocomplete.

Furthermore we also use the

class:someClass={someBoolean}

.someClass {
    @apply (...)
}

Of svelte quite frequently, since this short syntax can only be used for a single class @apply is very useful.

And while I appreciated the hard work put on Tailwind 4 and all the amazing future developments it enables and want to adopt it early I don't feel that (for my project, and many using svelte with TW3) this change in syntax and the work it will generate will be worth the benefits.

Brainstorming on how to keep the slick syntax we have grown accustomed to

• Since CSS modules are each processed separately, they have no @theme unless you import one.

Good point, I would wildly guess with no basis that most projects only use one theme. Would having a default theme configuration on the VITE plugin configuration be possible? One would be able to define a default theme to be applied as a default on all <style> tags, if a different one is needed then the explicit call would be needed.

Another question, forgive me if it is dumb, but I do lack this knowledge: If I add an class to an app.css file on Svelte and import it in the root +layout.css it is available across the board on all <style> tags. Why isn't this true for the theme?

• Tailwind needs to run 50 separate times, which leads to much slower build times and a worse developer experience.

Would this be slower than TW3, I have tested usign the imports on ALL my components in a 3M+ lines project with over 200 Components on the design system alone and saw no degraded performance of any kind when compared to TW3. Would it be possible that the frameworks in question are smart enough to only process the files that are changed during development severly mitigating the possible performance issues?

• we don't recommend using CSS modules and Tailwind together if you can avoid it. and we recommend avoiding <style> blocks in your components

Those seem to be unreasonable asks for the frameworks in question. And those seem to be established frameworks on the market.

Even more of a tall ask when CSS Modules are a native part of CSS that is most likely going to slowly grow in usage, specially by frameworks themselves as this featured seems to be very effective for how we write CSS in modern frameworks. If as part of the Angular renaissance they decide to also use CSS Modules would this hinder @apply there as well? This didn't seem to be an issue with TW3, or was it?

If this was an issue with TW3 how did it work before? Can we bring some of it back even with the aforementioned concerns?

If this was not an issue with TW3 this means that TW4 made a downgrade on that use case, would it be possible to have a flag of sorts to disable the features on TW4 that cause issues with CSS Modules and Svelte by consequence? I would be happy to revert to the old config format or giving up the improvements on compilation time if it meant keeping the old syntax back.

Usage of the new VITE plugin

As I mentioned before, since tailwind owns the VITE plugin would it be possible to have something like with postcss maybe <style lang="tailwindcss"> that would mark style tags to have the proper theme imported or something similar.

@ranseur92 provided a first draft of an idea, unfortunately it breaks HMR, but would something along those lines work or is that a dead end?

Sorry if I am being insistent, but as a Tailwind and svelte user who uses this combination in several projects handled by teams with several developers the syntax inside the <style> was perfect as it was. It simply worked, no shenenigans required, auto complete and all. I just want to maintain it in TW4.

This downgrade on the syntax for the developer obfuscates the great work in TW4, and I want to be on the first ones to migrate to TW4 when it is production ready.

[zheung]

It's too one-sided to discuss @apply using only color-related examples.

There are more uses for @apply.

I like your example. It's very good practice to use CSS variables directly if you only define colors. Tailwind will calculate all the colors for me, and there is no need for Tailwind to process them again.

<template>
  <button><slot /></button>
</template>
<style scoped>
button {
  background-color: var(--color-blue-500);
}
</style>

But in practice, do we really only need to define colors?
In the projects I've worked on, usually I also need to define margins, height, width, etc etc for the button.
We all want to centralize common styles in style blocks. Only some of the styles that need to be dynamically computed or specialized will be written directly in the HTML:

<style scoped>
button {
  @apply block p-4 h-8 leading-8;
  background-color: var(--color-blue-500);
}
</style>

@apply provides us with a simple and easy way to do this.

Do I need to change the block, p-4, h-8 presets in my project?

No, hardly!
The presets provided by Tailwind are excellent. I don't need to change these color-unrelated presets. In v3 or even v2, it's only necessary to add to them, not modify them.
With the presets virtually unchanged, why can't I use a global theme with a default base?
If presets like block p-4 use the native writeup that evades Tailwind handle, there's no point in continuing to use Tailwind.

Imagine these scenarios:

1, A small website needs only one color theme;
2, The site completely allows users to customize any color to be the theme color. At this time it is often more necessary to use js codes to control the color in real time, rather than through Tailwind to traverse all the colors.
3, the development of a common module, this module may exist in a completely different website. Color is unknown to the module developer. The only thing known is that there will be a theme color passed in as a parameter.

In these cases, importing a theme for every blocks or style files just adds a meaningless coding burden. Themes are not something developers need to care about.

For what I've tried so far, I don't think v4 handles single theme or color uncontrollable or unknowable situations well. This will make it difficult to upgrade my project from v3 to v4!

[felipeapfer]

Same issue with large svelte codebase. Started migrating but gave up after reading this thread, I agree with @zheung most projects do not need multiple configs.

[shawnchong]

HUGE THUMBS DOWN on the commenter, the explanation and the reasoning. If vue/svelte deals with scoped well, and tailwind doesn't it should just be stated Tailwind doesn't support vue, period. There is a good reason why there is <style scoped> for easy custom page css not using the terrible design idea of putting the css inline.

[lucas-subli]

I just found a great example of the very thing I want to avoid by using apply:

https://github.com/themesberg/flowbite-svelte/blob/main/src/lib/buttons/Button.svelte

This file has a hundred lines of code inside the style tag simply used to define styles.
Styles should live either in the HTML body of the component or in the style tag.

IMO code could be cleaner if they had done it like:

<style>
  .alternative  {
      @apply text-gray-900 bg-white border border-gray-200 (...)
  }
  
  .light {
      @apply text-gray-900 bg-white border border-gray-300 (...)
  }
  
  (...)
</style>

The script tag would look cleaner and smaller, auto complete and tailwind auto-sorting would work better in the <style> tag, developer would be able to selectivly choose where to look for design bugs vs logic bugs.

I think most (if not all) of what they are doing with styles in JS there could be easily achived with some @apply css. I know that in the components libraries that I have worked it cleaned up and isolated the styles from the script very effectively

@apply is great for components with multiple styles.

[logaretm]

As a Vue developer and working with a very large codebase, I agree with @lucas-subli on the ergonomics of this being less than ideal. I ran into it today and was confused for some time till I found this discussion.

I don't really consider this a workaround or anything, this is the API you need to use when you want to reference Tailwind theme variables from a totally disconnected entry point which is how these style blocks work.

I understand the argument here and it makes sense for these kinds of apps. But at the same time, many apps have a single theme or design token set.

Perhaps a compromise here is to keep this behavior as a default but offer a configuration that the dev could set to tell tailwind that we only follow only one theme config, not sure how feasible is that.

@import 'tailwindcss';

/* IDK, anything that would let tailwind know to use the existing config for scoped Vue CSS */
/* Maybe possible values are 'default' | 'all' or whatever */
@tailwind-scope 'all'; 

[matthiasPOE]

exact same problem here.

[feloot]

Same issue here with Vue3 only.

I started moving all the component css to tailwind classes on elements and it ended up making things messy with elements that have just too many classes in scenarios such as the one described in this thread.

It certainly is more rigorous but it ended up hurting code readability and made things worse than they were before.

Sadly I've decided to revert back to v3 because of this, until there is a clean solution.

[mohamad68]

It seems impossible to update to Tailwind v4 if you’re using Vue 3, Vite, and have a lot of @apply in your components. How are you supposed to import Tailwind into every Vue component just to use@apply ? I tried doing it, but it doesn't work either. My design was completely ruined. Even with the auto-update, @apply still doesn't resolve properly. It feels like Tailwind is dead in v4.

[hmt]

we moved all <style>s into *.css files which work just fine with @apply.

[Bassadin]

@mohamad68 how did you deal with this in the end?

[eastoid]

how did you deal with this in the end?

probably either switched off of tailwind or imported tailwind in each style block

[hyunbinseo]

That is quite offending. I guess I am stuck on Tailwind v3 on legacy projects.

A ton of confusion amongst Tailwind users comes from not realizing that if you are using CSS modules, or <style> blocks in Vue/Svelte/Astro, your CSS pipeline separately for every single one of those blocks.

50 Vue components using <style> means Tailwind runs 50 separate times.

https://x.com/adamwathan/status/1890404835888910467

For the best build performance, don't use Tailwind features in CSS modules or Vue/Svelte/Astro <style> blocks, just rely on CSS variables.

https://x.com/adamwathan/status/1890405698153972130

[shawnchong]

That defeats the purpose of tailwind. just don't use it if they force that, tailwind is not necessary.

[andymerskin]

"Don't use Tailwind features" is an... interesting take. The whole point is to minimize typing and constrain your CSS to a set of building blocks based on a theme (colors, spacing rules, etc.). While I understand in the past @apply has been frowned upon, Tailwind really doesn't have any other concept of "mixins" you can use for repetitious styling, in a way that supports complex CSS rules + selectors.

If it shouldn't be used within mainline CSS scopes from popular frameworks like Vue or Svelte, what's the point? In the React world, the fact that Twin.Macro is really the only library that allows @apply-like behavior inside Styled Components is kind of depressing, given that it's not going to support Tailwind v4 — and there's no equivalent officially supported by Tailwind.

It's easy to create components with styles applied directly to elements, or simply repeat the utilities used on a small handful of similar elements like the Tailwind guidelines recommend, but what if I need sets of shared utilities across different files? I suppose using vanilla CSS files with @apply used in classes works fine, but you lose the ability to scope CSS if needed.

One example in our project is: we have 3 different text input components that each have their own behavior depending on certain needs, where it would be overly complex to keep all that logic in 1 component with a few variants. In order to share our base input styles built on Tailwind, we went with a neighboring CSS file using @apply in global classes we can use:

/* TextInput.css */
.input {
  @apply px-3 py-2 bg-white text-black rounded ...;
  /*Yada yada, lots of utilities!*/
}

.input-danger {
  @apply ...;
}
  
.input-another-variant {
  @apply ...;
}

If we followed the official guidelines, we would need to keep track of all these utilities, with their conditions/variants, across 3 (or more) component files, and it almost guarantees we would break our styles because they'll eventually fall out of sync.

The other alternative is exporting strings of classNames that can be reused across components with twMerge and clsx, but this prevents us from using @apply in nested rules where we have more complex needs.

Using Tailwind programmatically (i.e. in JS) and other contexts in a repeatable way is part of why it shines.

[M1CK431]

@adamwathan you say something very interesting earlier:

There's no way to know if that is supposed to be blue or red without loading the relevant theme configuration.
So just like in JS when you need to import something to use it, the same thing is true with v4.

In JS, there are multiple way to globally import or auto-import things. It looks like most people have only one "theme configuration" and so, need a way to globally import or auto-import it everywhere (incl. scoped CSS). Wdyt about adding a way to do that easily, explicitely in V4?

[Nagell]

Tailwind is compatible with CSS modules and can co-exist with them if you are introducing Tailwind into a project that already uses them, but we don't recommend using CSS modules and Tailwind together if you can avoid it.

@adamwathan You mentioned that using Tailwind within CSS modules isn't recommended, which makes sense from a performance perspective. You also brought up the approach of using var() to reference Tailwind variables directly.

TL;DR:
It's a great initiative, but despite being recommended, it doesn't feel fully supported - whereas @apply is.

Long version:

• Neither theme() nor var() in Tailwind v4 are fully supported by Tailwind CSS IntelliSense. One of Tailwind’s biggest strengths is its excellent autocomplete/IntelliSense, which currently only works reliably with the @apply rule, which encourages usage of it even more. If var() is the recommended approach and is expected to gain wider adoption, perhaps this proposed enhancement deserves more attention:
  [Feature]: Provide VS Code Autocompletion for Tailwind's Generated CSS Variables tailwindcss-intellisense#1209
• While var() is recognized by Tailwind and the referenced variable gets added to the global styles, this only happens after a manual refresh. In other words, it breaks HMR (at least in a Vite + Vue app).

[metroite]

Why enforce your beliefs on tailwindcss users?

[metroite]

A Vite plugin solution for Svelte that works without importing it a billion times:

1. Create the plugin

SvelteTailwindApply.ts

import type { Plugin } from "vite";

export default async function SvelteTailwindApply(): Promise<Plugin> {
  return {
    name: "svelte-tailwind-apply",
    api: {
      sveltePreprocess: {
        style: async ({ content, filename }: { content: any, filename: any }) => {
          if (filename.endsWith(".svelte")) {
            const newContent = `@import "@app-css" reference;\n${content}`;
            return { code: newContent };
          }
          return { code: content };
        },
      },
    },
  }
};

2. Append the plugin inside of vite.config.ts

plugins: [sveltekit(), tailwindcss(), SvelteTailwindApply()]

3. Configure the path to the global styles as an alias inside of vite.config.ts

resolve: {
	alias: [
		{
			find: '@app-css',
			replacement: resolve(__dirname, 'src/app.css')
		},
	]
}

4. Make sure to correctly import everything

It should roughly look like this:

vite.config.ts

import { sveltekit } from '@sveltejs/kit/vite';
import tailwindcss from "@tailwindcss/vite";
import SvelteTailwindApply from './src/SvelteTailwindApply';
import { defineConfig } from 'vite';
import { resolve } from 'node:path';

export default defineConfig({
	plugins: [sveltekit(), tailwindcss(), SvelteTailwindApply()],
	resolve: {
		alias: [
			{
				find: '@app-css',
				replacement: resolve(__dirname, 'src/app.css')
			},
		]
  	}
});

I don't agree that @apply is disgraceful. Good examples have been provided by @lucas-subli and there are many more; like enhanced CSS selectors that might go beyond the Svelte component and standardized Tailwind values instead of relying on arbitrary values inside CSS classes.

[eastoid]

this solution works and also fixes css scoping issues for things like custom variants. thanks
edit: the solution introduces some odd things like fetching the css file clientside, it might be a config issue, but i will try to use this solution instead for now

function injectGlobalCSS(cssToInject: string): Plugin {
    return {
        name: 'inject-global-css',
        enforce: 'pre',
        transform(code, id) {
            if (!id.endsWith('.svelte')) return null;
            return code.replace(
                /<style(\s[^>]*)?>/g,
                `<style$1>\n${cssToInject}\n`
            )
        }
    }
}

export default defineConfig({
    plugins: [
        injectGlobalCSS(`@import "/src/app.css" reference;`),
        tailwindcss(),
        sveltekit(),
    ],
})

[shawnchong]

Thanks @eastoid - we already are kinda not going to tailwind4. It's very VERY annoying we chose Tailwind, and now the author is acting up and telling us "how to do things", when the reasoning and totally stupid. Also the proper work around just makes using tailwind look lik garbage, imo. Not just me, but also other projects I work on (other teams and companies). Who TF puts in tailwind into the dom in large quantities? Answer: VERY NOOB front-end UI devs.

[eastoid]

i agree, and even though my plugin solution sort of works, its still a pain to use, i might just have to start pasting that syntax into style blocks by hand. big step down from tailwind v3 for what seems like no real reason

[jamesst20]

Hi agree this is a huge downgrade going from Tailwind v3 to v4.

While I do agree the goal of Tailwind is writing the least custom CSS as possible, there are some scenarios where we have absolutely no control and we must override existing CSS coming from other library.

I'm giving a simple exemple in our use case in a Svelte app. We have a "FormSelect" component that uses the "Svelecte" library under the hood and update its styling so it matches our need. Moving from Tailwind 3 to 4 forced us to update the component style like so:

In my opinion, it was much cleaner and clearer previously.

Also, previously we were protected against typo such as text-bluee-500. I would have been warned by the compiler that text-bluee-500 doesn't exist. We no more have this safety.

[shawnchong]

When we were going to tailwindcss4 and my dev told me what we had to do, all I could do is laugh at the idiocy of this. The whole point of using scoped styles for some (in my case) vue pages, is to quickly develop and keep CSS styles separated with the dom. If their processor can't handle it, that's basically on Tailwind devs and authors being noobs.

From what my dev told me, it's the author of tailwind that is forcing his idea upon us. I see the shills and follow-the-leader mentality of non-experienced I-do-my-at-home crap projects blind followers agreeing.

Tailwind was ONLY useful as to reduce the # of chars to have some standard definitions and some good functionality we didn't have to write ourselves. To tell us that with style scoped, we need to add some stupid line, well that's on the tailwind creator and his initial design as being trash (ie: similar to the entire webpack idea which right from the start was stupid, and now we use vite). That should be allowed and handled by default PERIOD or be in a configuration file.

Again, the whole point of tailwind is cleaner CSS and that includes using <style scoped> simplicity of "css modules" to allow fast coding, ease of reading. Vue/Svelte/Astro have a good idea of scoped styles, tailwind needs to address this, and include simple configuration to handle it, regardless of optimization and speed.

[M1CK431]

Hi everyone,

As already stated in my previous comment, the real issue is the lake of automated, globally configured, @reference injection in Vue SFC components. So I wrote a Vite plugin which solves this issue: https://github.com/M1CK431/vite-plugin-vue-tailwind-auto-reference/

Developing this plugin took quite a bit of effort. If you find it helpful, please consider...

• 🌟 give a star on the github repo
• ☕ don't be shy with the Buy me a coffee button

Additionally, I urge @adamwathan to includes this feature in the official @tailwindcss/vite plugin directly.

[Vercris]

Hello, I am using your plugin but for some reason the extension of Tailwindcs Intelissense no longer works and does not let me see the self -fulfilled of the Tailwindcs classes you will know why does that happen?

[M1CK431]

Looks like an issue with Tailwindcss Intelissense vscode plugin. I don't experience that myself so I don't know, sorry.
Perhaps the vscode plugin expect the @reference to be present in your code in order to suggest available classes 🤷🏼‍♂️
Since my plugin add it "on the fly" using Vite transform hook, there is nothing in your code. I plan to add an option to automatically add @reference in the code instead. Perhaps it could solve your problem.

[zheung]

I feel like I'm nearing the end of my tailwind career. My projects have recently migrated to uno. The company I work for is also planning to migrate to uno. The components we have here are not suitable for continued development with v4. Based on the future of v3 and the incompatibility of v4, we have to leave Tailwind gradually.

[wldrve]

Will probably have to do the same.

[jamesst20]

@zheung

I have checked UnoCSS and I was unable to have with Vite multiple entrypoints and Uno which is pretty useful for splitting CSS from admin/web etc.

With tailwind it's easy to have multiple different setup and @source

[lucas-subli]

I think the key takeaways from this discussion are reasonably straightforward:

• Everyone here likes Tailwind and wants to continue using it.

• Tailwind V3 worked well for everyone, including in terms of performance.

• Most people were excited about Tailwind V4 and preferred to migrate sooner rather than later.

That said, some frameworks face technical constraints due to differences between their internal CSS handling and Tailwind’s design. This has led to a few issues:

• Regardless of how Tailwind is officially recommended to be used, real-world constraints in codebases demand an ergonomic approach to styling. This includes factors like legacy code compatibility, third-party CSS customization, componentization, and internal coding guidelines.

• Given the new guidelines and the lack of expected backward compatibility, migrating from V3 to V4 has proven troublesome and prohibitively expensive in large enterprise-grade codebases, where most developers have little time for such tasks.

• Many people here were happy with Tailwind V3 and are willing to opt out of the performance improvements, theming capabilities, and other new features in V4 to retain the old ergonomic @apply behavior.

I don’t think there’s much more to add beyond these points, and this thread will likely just reinforce them over time.

Hopefully, the Tailwind team can provide a clear commitment to one of the possible paths forward:

• If this change is final, confirming it would help those who need to either accept it and move forward or explore alternatives.

• If improvements are being considered, acknowledging that would give those affected a reason to wait for an official solution rather than resisting the changes indefinitely or using home-made workarounds.

[lucas-subli]

Interesting, thank you for clarifying.

Does it incur in the aforementioned performance penalties of rerunning tailwind for each use of the directive? Are there any down sides?

And most importantly, will a Svelte version follow soon? Please? 🥺 🤞

[M1CK431]

Does it incur in the aforementioned performance penalties of rerunning tailwind for each use of the directive? Are there any down sides?

There is no performance penalties or down sides because nothing is 'rerun" at all. This plugin use Vite transform hook to auto inject @reference when needed, then tailwind parse the result.

And most importantly, will a Svelte version follow soon? Please?

I don't use Svelte myself and my plugin isn't specifically designed for it, however you could still give it a try just by passing it the "good" option. For example, { include: /\.svelte\?.*type=style/ } might give interesting results... 🤷🏼‍♂️

For completeness, you should also take a look to that comment which is probably more accurate for Svelte: #15205 (comment)

[lucas-subli]

I see, I meant the inherit performance from using the reference Adam mentioned.

If I understood correctly from his comment each time you use @reference on a CSS module it causes a new separate CSS module processing for the affected frameworks.

When using CSS modules, build tools like Vite, Parcel, and Turbopack process each CSS module separately. That means if you have 50 CSS modules in a project, Tailwind needs to run 50 separate times, which leads to much slower build times and a worse developer experience.

If I understood correctly not having @reference or applies in any shape on the file could somewhat boost performance, as tailwind does not need to parse the file. But I would rather have the @apply if the performance cost is not prohibitive.

But your plugin seems to have some nice options to fine tune where it is applied. I will try it later.

[M1CK431]

Don't worry too much about performance. This plugin has been tested on a codebase containing over 600 Vue components and more than 80k lines of code in total. The build time takes less than 1 minute... As for the development experience, server startup is instantaneous, as well as hot reloading. In fact, it's completely transparent. Note that the plugin is already optimized to only import @reference if the file contains @apply.

[jamesst20]

Not sure if other people are in the same boat as me but in my project, adding @reference in every Svelte components that used @apply directive did work however changing a single line of CSS while vite was watching would throw an error and then crash the process. That is for our Ruby on Rails application using vite. I have not tested the plugin listed above but I would expect the same to happen. It stopped when I got rid of all @reference in favor of plain CSS. I sadly don't recall the exact exception, but I remember I couldn't find much about it when googling it.

This is a great summary by the way @lucas-subli

[hyunbinseo]

If you are not using @apply in every singe Svelte component, you could try this in a SvelteKit project:

// svelte.config.js
const config = {
  kit: {
    // ...
    alias: { '$app.css': './src/app.css' },
  },
};

export default config;

<style>
  @reference "$app.css";
  a {
    @apply text-red-700;
  }
</style>

It works without much config, boilerplate, or plugin. It will also help with Tailwind performance.

I have created an issue to add this to the SvelteKit template alias. Thumbs-up will be appreciated:

• Add app.css alias for Tailwind CSS v4 add-on sveltejs/cli#515

[DouglasCalora]

What is the point of updating a lib and make it worse? Not working even with @reference!

Using: nuxt ui v3.1.0 + nuxt.

[jamesst20]

Not everything is worse. I believe the config inside the entrypoint CSS file is a major upgrade. It's much easier to have multiple Tailwind config within the same app for different app section like / for the web, /app for internal authenticated app and /admin for admin panel

[kirkbushell]

Not everything is worse. I believe the config inside the entrypoint CSS file is a major upgrade. It's much easier to have multiple Tailwind config within the same app for different app section like / for the web, /app for internal authenticated app and /admin for admin panel

I disagree. The CSS configuration leaves much to be desired, as there's things you now can no longer do, such as programmatic configuration (rare, but sometimes required), inability to alias entire theme palettes, worse user experience with scoped css... Overall I'd say V4 is a worse solution than V3 was, introducing a more opinionated approach to the use of Tailwind, rather than a better one.

[jamesst20]

Not everything is worse. I believe the config inside the entrypoint CSS file is a major upgrade. It's much easier to have multiple Tailwind config within the same app for different app section like / for the web, /app for internal authenticated app and /admin for admin panel

I disagree. The CSS configuration leaves much to be desired, as there's things you now can no longer do, such as programmatic configuration (rare, but sometimes required), inability to alias entire theme palettes, worse user experience with scoped css... Overall I'd say V4 is a worse solution than V3 was, introducing a more opinionated approach to the use of Tailwind, rather than a better one.

You can still use the JavaScript configuration

@import "tailwindcss";
@config "../tailwind.config.js";

But having that config directive in the CSS allows for easy config scoping per entrypoints