[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.

[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.