@applyBroken in Tailwind CSS v4.0 – No Clear Fix or Docs!

[JaquesBotha]

Tailwind CSS v4.0 @apply Bug Report

Introduction

I'm in the process of upgrading a large project, actually, five Blazor projects that all conjoin into one via components and different backends. Our focus with this project is to deliver an optimal UI experience to the end-user, which is why we use TypeScript, C#, and of course, our favorite, Tailwind CSS. Btw, huge fans!

Now, with that said, we have certain native components where we cannot add CSS classes to the component itself, making @apply an essential part of our workflow. However, after upgrading to Tailwind CSS v4.0, @apply is no longer working as expected, and there seems to be little guidance on how to transition projects that rely on it. This bug report aims to outline the issue clearly and request either a fix or detailed documentation on what exactly we need to do to overcome this.

What version of Tailwind CSS are you using?

v4.0.0

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

Webpack 5.97.1

What version of Node.js are you using?

v20.11.1

What version of npm are you using?

v10.7.0

What IDE are you using?

Rider IDE

What operating system are you using?

macOS

Reproduction URL

There's an active discussion on this issue where many developers are experiencing the same problem but no one has officially reported it yet. Rather than debating, I’d rather get a solution, so here’s the link to the discussion: #13336 (comment)(https://github.com/yourusername/tailwind-v4-apply-issue)

Describe your issue

After upgrading to Tailwind CSS v4.0, I encountered the following issues:

1. @apply Directive Not Functioning

• The @apply directive, previously used extensively in our CSS for class composition, no longer functions as expected.

• Example:

  .quickgrid thead th {
      @apply tw-bg-slate-100 dark:tw-bg-slate-800/70 tw-py-4;
  }
  • This results in build errors indicating unknown utility classes such as:

  Error: Cannot apply unknown utility class: tw-transform
  Error: Cannot apply unknown utility class: tw-table-auto
  

2. Lack of Clear Documentation for @apply Usage in v4.0

• The v4.0 documentation does not provide explicit guidance on how to use the @apply directive in non-Vue projects.
• One part of the documentation states that @apply should still work, but this is only relevant for Vue projects.
• Another section in the documentation (CSS Modules Compatibility) suggests using CSS variables instead:

  background: var(--color-blue-500);
  • This is not an ideal solution because it significantly increases the workload, especially in large projects where @apply is heavily used.

3. Backward Compatibility with tailwind.config.js

• The tailwind.config.js file appears to be deprecated or its usage has changed in v4.0 without clear documentation.
• Projects relying on configurations such as prefix: 'tw-' are experiencing issues with styles not applying correctly.

4. @apply is Necessary for Native Blazor QuickGrid Components

• In my case, I use @apply with Native Blazor QuickGrid components, where there is no alternative way to apply Tailwind classes.
• The current documentation does not provide any solutions for frameworks outside of Vue.

Expected Outcome

• A fix for @apply so that it functions as expected in Tailwind CSS v4.0.
• Clear documentation outlining the necessary steps to transition existing projects that rely on @apply.
• An explicit guide on how tailwind.config.js should be updated for v4.0.

---

Thank you for your attention to this issue!

[lightify97]

@JaquesBotha having the same issue. It's a really frustrating experience.

[kostekd]

Having the exact same issue right now.

[kostekd]

A workaround, which feels like cheating, is adding a reference to the CSS file with the Tailwind configuration

@reference './../../../globals.css';

The drawback is that you have to reference it in every single file, which is too cumbersome.

[DavidUntama]

Now wint te 4th version of tailwind you don't use @apply inside stryle tag of a component, it must be used in globall.css or another external css, thanks to vite

[lightify97]

@adamwathan

[JaquesBotha]

Right on! Its like the 4.0 shift was rushed. Too many major changes without proper testing

[bakikucukcakiroglu]

Absolutely! I tried to do a quick switch but the whole project is broken. Of course, there should be workarounds but too much effort and I don't have time.

[lightify97]

@JaquesBotha I think going back to V3 is the best choice here.

[adamwathan]

We missed the prefix changes in the upgrade guide, will make a note to add that. The automated upgrade tool should handle those changes for you though if you haven't tried it.

The main difference is prefixes look like variants now and always go at the beginning:

  .quickgrid thead th {
-     @apply tw-bg-slate-100 dark:tw-bg-slate-800/70 tw-py-4;
+     @apply tw:bg-slate-100 tw:dark:bg-slate-800/70 tw:py-4;
  }

Here's the general documentation for the prefix option:

https://tailwindcss.com/docs/styling-with-utility-classes#using-the-prefix-option

I'm not sure how Native Blazor QuickGrid components work but if the CSS for each component is bundled individually the way CSS modules/Svelte/Vue/Astro style blocks are, you may also need to use the @reference option to make sure your theme variables are imported in the right scope:

https://tailwindcss.com/docs/functions-and-directives#reference-directive

Quick search makes me suspect this may be the case because of this CSS isolation functionality, which implies every stylesheet is processed independently with no knowledge of any other stylesheets.

[TGlide]

its also happening with me, without prefixes. Using Svelte

[JaquesBotha]

Response to Tailwind Developer on @apply and Blazor Compatibility

Hey there,

Thanks for the response! I appreciate the clarification on the prefix changes, and I see how that aligns with the new variant structure. That said, the prefix change is really just a small part of the bigger issue I'm facing with Tailwind v4.0 in a Blazor Server environment.

Blazor Is Not Vue (Or Other Scoped CSS Environments)

I noticed in your response that you referenced Blazor QuickGrid's CSS isolation as being similar to how Vue, Svelte, and Astro process styles. However, this assumption isn't entirely accurate for Blazor Server (which is what I'm using) in conjunction with Webpack, TypeScript, and PostCSS.

• In Blazor Server, we do not have component-scoped styles the way Vue, Svelte, or Astro do.
• CSS files are bundled traditionally via Webpack/PostCSS, meaning every Tailwind utility class should be accessible globally unless something is actively blocking them.
• There’s no automatic "style scoping" in Blazor Server that would prevent @apply from working. In fact, @apply has worked flawlessly in previous versions of Tailwind, making this a regression rather than a Blazor-specific issue.

Why @reference Isn’t a Solution Here

I’ve already tried using @reference as suggested, but it does not resolve the issue. If Blazor Server worked like Vue, I would expect:

1. Tailwind to correctly apply styles within each scoped CSS file.
2. A missing reference to cause an explicit error, rather than breaking @apply entirely.

Neither of these behaviors are happening. Instead, @apply is failing even in cases where the styles should be globally accessible.

What I Need from Tailwind

Rather than focusing on workarounds (like @reference or changing the prefix), I need a clear explanation of why @apply is breaking even in non-scoped, globally processed CSS.

• Is this an intentional limitation in Tailwind v4.0, or an unintended side effect?
• If this is an intended change, what is the exact migration path for users who rely on @apply in a global CSS setup?
• If this is a bug, what information do you need to reproduce and resolve it?

Again, I really appreciate the work the Tailwind team is doing. I just want to make sure that this upgrade doesn’t break workflows that were previously supported—especially in frameworks like Blazor Server where @apply is an essential tool.

Looking forward to your insights!

[adamwathan]

@JaquesBotha If the CSS is truly one global stylesheet (all of the stylesheets from your components are concatenated into a single stylesheet before being passed to Tailwind for processing) then everything should work exactly as it did before.

The key thing to understand is for things like @apply bg-red-500 to work, --color-red-500 needs to be defined as a theme variable. In v3 and earlier, the tailwind.config.js file was an assumed convention, and even though scoped styles were all processed independently in v3 as well, we could automatically pick up that config file for each independently processed stylesheet by convention alone.

In v4 with configuration moving to CSS, we can't make assumptions about what your CSS file is called or where it lives, so if you have custom configuration in one CSS file that you need available in another CSS file, you need to explicitly import it using @reference, just like you how you import functions in other programming languages.

So the issue isn't to do with "scoping" it's just whether the CSS is actually processed together as one big stylesheet, or if each stylesheet is being processed one by one without the rules from the other stylesheets being present.

Imagine you have these two stylesheets:

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

@theme {
  --color-potato: #d2a062;
}

/* two.css */
.foo {
  @apply bg-potato;
}

If these files are conceptually processed independently, sort of like this:

npx @tailwindcss/cli -i one.css -o one.dist.css
npx @tailwindcss/cli -i two.css -o two.dist.css

...you'll get an error when compiling two.css because --color-potato does not exist. It's as if the files are on totally separate computers, there is nothing linking them if they are compiled separately.

This however of course will work fine:

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

@theme {
  --color-potato: #d2a062;
}

.foo {
  @apply bg-potato;
}

npx @tailwindcss/cli -i everything.css -o everything.dist.css

...because now --color-potato is defined since it's all one build.

Imagine you had one project that had a client.css file for the client and an admin.css for your internal backed, and both of them defined a custom --color-primary:

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

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


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

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

Now you have some other component CSS file like this:

/* foo.css */
.foo {
  @apply bg-primary;
}

Is that supposed to be blue or red? It's impossible to know because the color isn't defined and we have no way of making any assumption about what it should be. We could in v3 because of the global tailwind.config.js file, but again in v4 there's no concept of a magic autodetected primary CSS file to automatically use as the context for every other CSS file in the project.

But you're saying that the CSS is global and they aren't processed independently, so what do you mean exactly when you say "@apply is breaking"? Is there an error message? What does the error say?

If you can provide a reproduction we can boot up a Windows environment and take a look. It might be a bug if the CSS truly is all concatenated together and processed as one stylesheet but the fact that @apply isn't working really makes me think Blazor is processing each stylesheet independently.

[OliverRC]

I was facing a similar Cannot apply unknown utility class issue and the root cause was because the css I was brining over was relying on custom colour names but I had not defined the css variables in the @theme directive.

[codepilotsf]

In Rails, with v4, we get a stylesheets/application.css and a tailwind/application.css. All @apply directives in my stylesheets/application.css are silently ignored. They just don't do anything. Using @apply in my tailwind/application.css works as expected.

[mohamad68]

I have dozens of Vue components with @apply in the <style> tags. I tried adding @import and @reference, but it's still not working. It should either restore @apply support without needing any extra imports or automatically upgrade and handle @apply to make it work again.

[adamwathan]

I have dozens of Vue components with @apply in the <style> tags. I tried adding @import and @reference, but it's still not working. It should either restore @apply support without needing any extra imports or automatically upgrade and handle @apply to make it work again.

@mohamad68 Can you please provide a reproduction? Here's a Vue + v4 project where it is working as expected:

https://github.com/adamwathan/vue-v4-apply

[emercab]

It worked for me!

[neonelemental]

@adamwathan That's actually broken, but it's a subtle difference to what you've got here that produces the issue. I'm not sure exactly what the issue is, but if you render a component with the @reference and @apply rather than doing it in App.vue, you'll see that @apply is not working in the component context.

To reproduce the error in your example app, I made the following changes:

// in App.vue

<script setup>
import TestComponent from './components/TestComponent.vue'
</script>

<template>
  <div>
    <TestComponent/>
  </div>
</template>

// in components/TestComponent.vue

<template>
    <h1 class="test">
        Test
    </h1>
</template>

<style scoped>
@reference '../style.css'

.test {
    @apply text-red-500 text-4xl;
}

// or this, which didn't work for me either...

h1 {
   @apply text-red-500 text-4xl;
}
</style>

The result is that the text in the h1 is neither large nor red as I specified in the @apply statement.

[neonelemental]

@adamwathan Hmm, I toyed around with this and it's kind of flakey. I played around some more with this and got the applies to work copy-pasting your example applies. I'm not really sure what's going on there, but I can confirm I have seen this both not work and work.

I don't know if there's something going on with vite, but when I pulled this down and added the above code, it did not work. At some point I moved some files around and copy-pasted code, and it started working and I was unable to reproduce what I was originally seeing (small, black text instead of 4xl red text)

[neonelemental]

I'm not 100% sure what the intended behavior is for @apply, I'm just started using tailwind on a personal project and have only ever used tailwind 4. Here's what I am observing. If I comment out the applies in App.vue and add the component for TestComponent, it will render the basic black text. Once I uncomment the App.vue references, all the sudden things start working again, but then I cannot change colors.

My advice would be to take 2 components and add @reference and @apply and start making changes:

1. Try changing one to blue, one to red
2. Try changing one to using a class definition and one to using an element definition
3. Comment things out and uncomment things.

I can't get it to behave consistently at all, and it definitely feels like <style scoped> is not working, because to me it seems like they're interfering with each other, which you would not really expect.

[loukamb]

I can also attest that my website (using Astro) has broken in a re-deployment that installed the latest minor version of Tailwind (worked fine on 4.0.3, has problems on latest). Despite no code changes on my end, variables in non-root stylesheets such as var(--text-3xl) simply ceased to exist after the minor update, even though I inserted a @reference statement at the top of said stylesheets to make sure that statements such as @apply text-3xl would receive styling. This pretty much broke my entire blog layout, as well as the layout of two other sites I am also maintaining.

I find it quite impressive that a project as large as Tailwind wasn't able to catch a significant regression in a minor version update (as stated above, it worked fine on 4.0.3, but broke on latest). I am not alone in finding the Tailwind 4.0 "improvements" to be more providing of frustration than anything else, even after consulting the documentation and following the upgrade process correctly. Apparently, my patience in upgrading correctly has been punished with 4.0 minor updates randomly breaking my website if I dare re-deploy.

For now, I will mitigate these problems by pinning my dependencies to 3.0 for each of the projects mentioned above. I would consider re-categorizing 4.0 as a beta (again) until it becomes appropriate for production use.

[isaacmattern]

I'm having the exact same experience as you - completely unable to get any @apply rules working outside of my main global css fie. What a headache. I expect better from such a widely-used package.

[shadowdreamer]

So it is still not safe to use @apply and we have to write a lot of @reference? I tried nuxt-ui v3 with tailwind v4, but I don’t think it is suitable for production yet.

[thaikolja]

I agree.

[Akeemovic]

For someone using multiple CSS files, the @reference crap doesn't even work.
Better to stay on v3 than downgrade to this v4 garbage.

[YutoYasunaga]

Agree, this current v4 is disaster.

[wldrve]

Tailwindcss just went from best to last with the v4. I mean what in the world were you thinking with going full on CSS?

I just tried updating one of our company's demo projects and I had to adjust 250+ Vue components, multiple .less files, remove the tailwind.config.js and I still can not get it to work. And that is a DEMO project. I have lots more (production) waiting on an update.

Just the fact that the prefix logic has changed is cumbersome, at least for someone who is not using "tw" as a prefix. Also trying to deprecate a perfect file such as tailwing.config.js to include a GLOBAL config and trying to do the same with @theme directive and CSS variables, which apparently do not work globally anymore and have to be referrenced in each and every file? Man... You're really trying to make it harder to use and of course masively redundant.

I will be going back to v3 immediately and if things do not change or adapt in the new version, I might have to think of other options than Tailwind. I can't even imagine who will want to pay for the hours that I'll use to update this blunder in other a lot more massive projects.

And again, I can't grasp the idea, that this wasn't a beta, because it should still be in beta testing if you ask me.

[isaacmattern]

I completely agree. I have a very small NextJS app and used the official migration tool, but this bug would literally require me to either:

• add @reference and hardcode the full relative path to my global css file within every css file which uses the @apply directive
• modify webpack config to support a module alias so I can use the same path within every css file (this would still require adding @reference)

I'll be staying on v3 until this gets fixed - and if it's ignored I'll probably stop using tailwind in my projects. Being able to apply utility classes to custom CSS classes seems like a pretty straightforward piece of functionality, and it's frustrating to see that that's broken AND requires additional configuration/overhead after a v3 to v4 "upgrade".

[shadib0797]

Note:
@reference to each css file will mess up your HMR real bad, it just painfully slow

[M1CK431]

@isaacmattern Please give a try to my plugin: https://github.com/M1CK431/vite-plugin-vue-tailwind-auto-reference/
I create it exactly for that! 🫶

@shadib0797 I notice a very small performance penalty too. That's why my plugin add @reference only in <style> block which contains @apply. This mitigate that problem.

[M1CK431]

Hi everyone,

I just solve this issue for Vue users. Take a look here for details: #15205 (comment)

Cheers! 👋🏼

[vzakharov]

Does @reference not work for someone as it does not for me?

<style scoped lang="postcss">
@reference "tailwindcss";

.rand-button {
    @apply inline-flex cursor-pointer select-none items-center justify-center overflow-hidden relative
        // removed for brevity
}
</style>

The actual button does have a rand-button class on it, but the class includes no rules inside, according to the browser console.

(I'm using "tailwindcss" for the @reference instead of my actual stylesheet as an example because it still doesn't work.)

[M1CK431]

I guess it should be something like @reference "./tailwind.css"? 🤷🏼‍♂️
But I advise to use my plugin instead since it handles this (and many more) for you; https://github.com/M1CK431/vite-plugin-vue-tailwind-auto-reference/

[YutoYasunaga]

@vzakharov I'm using Rails with Vite, I tried @reference and some other but nothing working.

[YutoYasunaga]

V3 was significantly better than this frustrating V4. I maintain multiple Rails/Vue projects, and ever since the upgrade, deployment is completely broken.

[JNietou]

Have you tried the @M1CK431 solution?

[YutoYasunaga]

@JNietou Thanks.
But not working for me, I'm using Rails with Vite.

[M1CK431]

@YutoYasunaga could you please elaborate a bit? What have you try with my plugin? What is not working?
EDIT: If I understand correctly, your stack is Ruby on Rails for the backend (API) and Vite (VueJS v3) for the frontend?

[adamwathan]

and ever since the upgrade, deployment is completely broken.

Is this at all related to the @apply conversation here? Not sure how that would affect deployments. If you can start a discussion with some actual details/information, it's more likely people can help. There's not really anything we can do with this message.

[formbook]

I managed after much pain to migrate to v4

this is the structure I have now

/* index.css */

@import url("./checkbox.css");
@import url("./fonts.css");
...

/* Seems important that tailwindcss is imported AFTER other styles */
@import "tailwindcss";
@plugin 'tailwindcss-animate';

@custom-variant dark (&:where(.dark, .dark *));

@theme {
    --color-dark-bg: #141414;
    --color-dark-fg: #191919;

    --font-inter: "Inter", sans-serif;
	...
}

.border-neutral {
    @apply border-neutral-300 dark:border-neutral-800;
}

.text-secondary {
    @apply text-neutral-600 dark:text-neutral-400;
}

.flex-center {
    @apply flex items-center justify-center;
}

to use apply in the other files, reference the index

/* checkbox.css */

@reference './index.css';

.checkbox__control[data-checked] {
    @apply text-neutral-50 border-violet-600 bg-violet-600;
}

if you want to use a custom class in an @apply, you need to make it a utility

@utility text-primary {
    @apply text-neutral-800 dark:text-neutral-200;
}

.other-class {
	@apply text-primary w-full;
}

[cherepin]

but in this case if you want to use utility as class, you have to do also

@utility text-primary {
    @apply text-neutral-800 dark:text-neutral-200;
}

.text-primary {
   @apply text-primary;
}

which feels like workaround...

[YutoYasunaga]

I can't even build with this simple code.

$ tailwindcss -i ./app/assets/builds/input.css -o ./app/assets/builds/final.css --minify
Error: Cannot apply unknown utility class: ml-1

@import 'flowbite';
@import "tailwindcss" important;

@theme {
    --color-primary-light: #047857;
    --color-primary: #065f46;
    --color-primary-dark: #064e3b;
}
@custom-variant dark (&:where(.dark, .dark *));

.svg-inline--fa + span {
  @apply ml-1;
}

[M1CK431]

Looks like you are not using Vite bundler. My plugin is for Vite only so not applicable in your case, sorry.

[adamwathan]

I copied your setup and it works as expected:

Can you create a new discussion that includes a full reproduction? That's the only way to figure out what's misconfigured on your end.

[steinerd]

Found a workaround in Nuxt 3+ using Tailwind4

<template>
  <div class="list">
    Foo Bar
    <p>Bar Foo</p>
  </div>
</template>

<script lang="ts" setup></script>

<style lang="postcss" src="./chores.css"/>

/* <relative to sfc>/list.css */
@reference "../assets/css/main.css";

.-list {
  @apply bg-white; 
}

It would appear the tailwindcss/vite plugin doesn't even look in the Vue files, but if you have a standalone CSS, it's much more forgiving.

You'll still have to reference the original css file so it knows what the utility CSS classes are.

Completely defeats the purpose of a SFC but if you're in a pinch and need things to work on the newest stuff without an entire rewrite, this might help.

---

Edit (04/06/2025)
Issue seems to stem from the lang="postcss" explicit attribute assignment. Vite or Webpack isn't seeing it and it's not trying to run it through postcss.

I removed the lang="*" attribute from my style tag; and added

"css.lint.unknownAtRules": "ignore",

To my settings.json in my VSCode so it doesn't complain about at-rules.

Updated my nuxt.config.ts to use

///...
const mainCssPath = "~/assets/css/main.css";

export default defineNuxtConfig({
//....
 vite: {
    plugins: [
      tailwindcss(),
    ],
    resolve: {
      alias: {
        "main.css": resolve(dirname(fileURLToPath(import.meta.url)), `./${mainCssPath.replace("~", "")}`)        
      },
    },
  },
///...

});

And then I was able to write style tags in my SFCs like...

<style scoped>
@reference "main.css";

.chores-list {
  @apply bg-white; 
}

</style>

You'll end up missing some postcss syntax benefits, but I feel like this is the best standing workaround until it is fixed in the official releases.

[JaquesBotha]

I'm not going to lie, like others in this thread, we’ve managed to find a partial workaround. But that doesn’t change the fact that this situation highlights what happens when updates are pushed without proper planning or testing.

Version 4 feels like it was rushed out the door, with no clear recourse or rollback strategy for those impacted.

What frustrates me most are decisions made without transparent communication or meaningful community input. It doesn’t feel like feedback was considered, or even requested, before shipping breaking changes.

I’m a huge fan of Tailwind and have used it extensively. But structure and stability matter. We can’t keep shipping updates that solve one problem but introduce a dozen new headaches.

This release seems heavily optimized for frameworks like React, with minimal consideration for broader usage contexts. That’s not acceptable when Tailwind serves such a wide range of developers and platforms.

[adamwathan]

Sorry what issues are you running into now? We spent hours and hours working with you over the last couple of months to help you and last I checked everything was working the way it was expected to work?

Version 4 feels like it was rushed out the door

The first alpha was released in March 2024 and the stable release was tagged in January 2025. There was a nine month period where you could test it and help surface issues for us to resolve.

What frustrates me most are decisions made without transparent communication or meaningful community input. It doesn’t feel like feedback was considered, or even requested, before shipping breaking changes.

Tailwind is something we build and maintain for ourselves first and foremost — it's not a charity project where we build things for other people for free. We build what we need and try to design the experience we want, and we release it as free open-source software so other people can use it if they like it. They can also fork it, tweak it, and do anything else they want with it.

We definitely listen to feedback and implement changes that we agree with and make sense to us, but you're right that I won't generally make changes to the framework that are in conflict with my own vision for it or that will make it more difficult to maintain without meaningfully improving my own experience with the tool. Again it's free open-source software gifted to the internet for others to use if they choose, it's not a service we provide to meet your needs that we work on as free volunteer labor.

That’s not acceptable when Tailwind serves such a wide range of developers and platforms.

It's free open-source software, there is nothing I can do that is "not acceptable". I'm sorry you are having more issues (that you haven't articulated so we have had no chance to help even if we wanted to), but you are not owed anything here man 😕 We are not obligated to give you any of our time, and we have given you tons of it.

It's really important you understand this dynamic if you are going to continue to contribute to discussions here.

[JaquesBotha]

No issues at all, we are all good! Thank you for all your efforts. It was just an observation. Wasn't trying to pick a fight I get it! What you've done and created is phenomenal and I'm not being sarcastic at all here! I'm truly a fan.

[JaquesBotha]

Oh and NOT to mention that Tailwind Itellisense plugins in both VS Code and JetBrains (RiderIDE, WebStorm) also STOPPED WORKING all of a sudden!

[shadib0797]

@JaquesBotha Update Editor Settings json
Specifically "tailwindCSS.experimental.configFile": "<your-path-to-tailwind-css>",
it should work

[steinerd]

@shadib0797, this feels illegal. :D
The intellisense from the plugin works now, but I must go shower. I feel unclean. 😀

[danilo-bassi-simplisafe]

I was planning to migrate a big codebase that is using Tailwind 3 but I hate the idea to add the @reference to every file that uses @apply. I am using Angular 19. Is there any other workaround?

[thaikolja]

Unless this is planned to be fixed or changed, I don't see any workarounds that don't feel like hacking and meddling in some core code.

I personally am stuck with v4 in one project and have no choice but to always use class names.

I really hope this gets addressed at some point.

[jamieconnor]

You could put tailwind.css as in include in vite somehow, but you might want to turn it off for build?

…

On Wed, 16 Apr 2025 at 5:23 AM, Kolja Nolte ***@***.***> wrote: Unless this is planned to be fixed or changed, I don't see any workarounds that don't feel like hacking and meddling in some core code. I personally am stuck with v4 in one project and have no choice but to always use class names. I really hope this gets addressed at some point. — Reply to this email directly, view it on GitHub <#16429 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEAE5XRKHHWNNWCO2UUMED2ZVMBLAVCNFSM6AAAAABW5NRQHCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOBUGYYTCNI> . You are receiving this because you are subscribed to this thread.Message ID: <tailwindlabs/tailwindcss/repo-discussions/16429/comments/12846115@ github.com>

[thaikolja]

I'm not sure if I understand you correctly. How's this a workaround for using @apply in the <style> section of components?

[steinerd]

Potentially, if you convince Vite to put in the entire tailwind reference it will essentially be embedded in the entire site compile, making it so your <style> tags would be able to use @apply without explicitly putting a @reference 'tailwind... at the top of each <style> tag.

I tried something like this and it worked SOME of the time.

[M1CK431]

what about https://github.com/M1CK431/vite-plugin-vue-tailwind-auto-reference ?

[jamieconnor]

Well, if you tell vite to include tailwind.css for every file as part of its eslint building then it will know of every class. I haven't tried this, but maybe unplugin-auto-import/vite will work to import tailwind.css? Or maybe ` css: { preprocessorOptions: { css: { additionalData: ***@***.*** "@/styles/variables.scss";` } } } ` ?

…

On Wed, Apr 16, 2025 at 5:49 AM Kolja Nolte ***@***.***> wrote: I'm not sure if I understand you correctly. How's this a workaround for using @apply in the <style> section of components? — Reply to this email directly, view it on GitHub <#16429 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEAE5QCDWVZU2LZYD4RVFL2ZVPEFAVCNFSM6AAAAABW5NRQHCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOBUGY2DCMA> . You are receiving this because you are subscribed to this thread.Message ID: <tailwindlabs/tailwindcss/repo-discussions/16429/comments/12846410@ github.com>

-- Jamie Connor jamieconnor.com <http://www.jamieconnor.com/>

[evenfrost]

Just my two cents on the topic.

As for me, @apply is one of the main reasons I use Tailwind. I build my whole style architecture of client-side apps around it, and it really makes it easy to abstract and re-utilize common styles written in my Tailwind config. This change is why I plan to stick with Tailwind v3 (for now, at least).

I use CSS Modules with Tailwind (along with react-css-modules-like Vite plugin to make use of styleName), and my code looks as follows (this is just a made-up simple example):

// /components/Section.tsx

import '@/components/Section.module.pcss';

interface SectionProps {
  title: string;
  description: string;
  content: React.ReactNode;
  actions: React.ReactNode;
}

const Section = ({ title, description, content }: SectionProps) => {
  return <div styleName="section">
    <h2 styleName="section-title">{title}</h2>

    <div styleName="section-description">{description}</div>

    <div styleName="section-content">{content}</div>

    <div styleName="section-actions">
      <div styleName="action"></div>
      <div styleName="action"></div>
    </div>
  </div>;
};

export default Section;

/* /components/Section.module.pcss */

.section {
  @apply flex flex-col gap-4;
}

.section-title {
  @apply text-2xl font-semibold text-gray-900;
}

.section-description {
  @apply text-sm text-gray-900;
}

.section-content {
  @apply flex flex-col gap-4;
}

.section-actions {
  @apply flex flex-col gap-4;

  & .action {
    @apply flex-1;
  }
}

As you can see, the usage of @apply adds a semantic meaning to elements and helps differentiate them and read the code more easily, thus improving DX to a great extent. If I had to write <div styleName="flex flex-col gap-4"> instead of <div styleName="section"> in my TSX files, it would become a lot messier and more complicated to navigate through the codebase.

That's why I think @apply has its usage and needs some love in v4 as well.