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

[bennycode]

@adamwathan the latest version of the upgrade tool (@tailwindcss/upgrade) is broken so it doesn't handle those changes: #17768

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

[shniubobo]

In my case, adding a semicolon solves the problem:

@reference "../style.css";

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

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

[naj821]

This works. Thanks👍

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

[TeemuKoivisto]

Deprecating @apply is just stupid. Reusing classes is such a vital part of writing CSS fast I don't understand why it should be made harder to do. I often use apply, for example, for the rows of a list which reduces visual clutter and makes it easy to apply the styles to different html elements depending on the logic.

And the whole auto-migration is just broken as it does nothing except complain about Could not determine configuration file for: x which you have to manually fix yourself either way. What a disaster. Now I just stare at my tailwind configs in horror as I have to fix them for a dozens of different projects by hand one day. For not much of a benefit, I might add.

Also, I'm not sure whether shadcn has upgraded to v4 but I feel I have to do additional extra work of upgrading their components as well.

Okay this became a bit of a rant, but I just want to express my frustration of introducing needless churn in the most JS-way possible - breaking things because "it's better". Yeah, probably, but in my mind it gotta be a goddamn big improvement for making me waste my time on useless busywork like this.

[M1CK431]

what about https://github.com/M1CK431/vite-plugin-vue-tailwind-auto-reference ?
Also, you could give a try to UnoCSS.

[appleseed-iii]

aaaaa same issue

[sundaywork]

I finally found the way out - use "npx @tailwindcss/upgrade" as indicated on https://tailwindcss.com/docs/upgrade-guide. This seem to change the necessary pieces. Then remove all usage of utility classes in code.

[gregg-cbs]

Some notes which could help you

Number 1, most importantly:

After getting an error you need to cancel your terminal and rerun your project. What i have seen is that once tailwind errors in the terminal, even if you fix the error it keeps showing that same error. Stupid thing. So after every error, fix the issue and then rerun the terminal to test.

@apply does work

In css files @apply does work. In my svelte files they no longer work so i have removed them for now. I used the npx @tailwindcss/upgrade command to upgrade from v3 to v4.

Brace yourself for a myriad of issues

tailwind.config file has no effect anymore and so all config there is lost - i had a lot. My elements look different - from shadows having different weights, to flexbox behaving differently, custom font no longer working, primary and secondary colors gone... everything needs to be migrated to the @theme from what i can see.

Its not the end of the world or the worst though - I upgraded cause I want some v4 features and so the change will take a bit and be for the better just be prepared for them and take time.

[gregg-cbs]

I ended up reverting this upgrade. There were too many styling inconsistencies to move forward with the upgrade at this time. Especially with flexbox and font weights. I like the new v4 way of working though just not for us right now.

[MR314159]

I just moved my reusable component definitions to index.css and now it’s working again in Tailwind CSS v4.

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

@theme {
  --color-primary: #ff49db;
}

@layer components {
  .btn-white {
    @apply border border-gray-200 px-3 py-2 rounded-md font-medium text-sm transition-colors duration-200 w-full;
  }
}

And I use it like this in my React components:

<button className="btn-white">Click me</button>

Is this the recommended way to do in v4?

[adamwathan]

Definitely better to set things up as one global CSS file (even if that file itself imports a bunch of other CSS files) like you have here. Means Tailwind is only run once, instead of n times like it would be when using n CSS modules or <style> blocks in Vue/Svelte components.

[Vrezerino]

The update broke my darkmode despite using npx @tailwindcss/upgrade. For instance in globals.css this used to work:

@utility body-dark {
  background-image: url('/img/sky-dark.jpg');
}

But while toggling the theme, I can see in Inspector that the rule is added, but it does nothing now since it has been struck through (because it's now nested?):

@layer utilities {
.dark:body-dark {
&:where(.dark, .dark *) {
background-image: url('/img/sky-dark.jpg');
}
}
}

[wongjn]

If you look through the styles in the inspector pane, you should be able to see which rule is overriding it.

[Vrezerino]

If you look through the styles in the inspector pane, you should be able to see which rule is overriding it.

Well above it is the light mode selector that wont disappear upon toggling

body {
  color: rgb(var(--foreground-rgb));
  background-image: url('/img/sky1.jpg');
  background-size: cover;
}

[wongjn]

That's probably it then. Try placing the rule in @layer base:

@layer base {
  body {
    color: rgb(var(--foreground-rgb));
    background-image: url('/img/sky1.jpg');
    background-size: cover;
  }
}

[Vrezerino]

That's probably it then. Try placing the rule in @layer base:

@layer base {
  body {
    color: rgb(var(--foreground-rgb));
    background-image: url('/img/sky1.jpg');
    background-size: cover;
  }
}

Thanks!