@apply directive not working anymore?

[tamerkalieh]

Hello! I have a fresh vue3 installation and added tailwind according to the "vite" installation guide: https://tailwindcss.com/docs/installation/using-vite

Adding tailwind classes in the template elements directly works just fine but I'm used to use the @apply directive within the style section of my vue templates. The moment I'm using sass in my style block, the @apply directive does not work anymore. However, sass itself works. As an example:

❌ @apply with sass does not work

<style lang="sass">
@reference "tailwindcss"

.main
  @apply text-2xl font-bold text-red-500
</style>

✔️ @apply works without sass

<style>
@reference "tailwindcss";

.main {
  @apply text-2xl font-bold text-red-500
}
</style>

✔️ sass works without @apply/@reference

<style lang="sass">
.main
  background: red
</style>

Note:
Official docs about the @apply Directive

Official docs about using @reference first so I can use @apply inside the style block

package.json:

{
  "name": "sample-app",
  "version": "0.0.0",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "format": "prettier --write src/"
  },
  "dependencies": {
    "@tailwindcss/vite": "^4.1.4",
    "tailwindcss": "^4.1.4",
    "vue": "^3.5.13",
    "vue-router": "^4.5.0"
  },
  "devDependencies": {
    "@vitejs/plugin-vue": "^5.2.3",
    "prettier": "3.5.3",
    "vite": "^6.2.4",
    "vite-plugin-vue-devtools": "^7.7.2"
  }
}

[wongjn]

Tailwind is not compatible with Sass.

---

As an aside, Adam Wathan (creator of Tailwind) does seem to advocate avoiding @apply:

• https://twitter.com/adamwathan/status/1226511611592085504
• https://twitter.com/adamwathan/status/1559250403547652097
• https://x.com/adamwathan/status/1890406016291938701

[tamerkalieh]

Mhhm... I see... That sass thingy is new, it worked before v4. I really can't wrap my head around having an element with like 1-20 classes inside my markup. I find it not only ugly but also somehow harder to maintain.. especially when having like multiple different rules for sm, md, lg, xl for the same element.

There I used to do:

@screen sm
    .my-class
        @apply px-2
        
@screen md
    .my-class
        @apply px-4
        
@screen lg
    .my-class
        @apply px-8

Which maybe looks "longer" than having: px-2 md:px-4 lg:px-8 but when having multiple elements with different rules per screensize, it was really nice having a place in my template where I exactly knew: here is mobile, here are the overwrites for md and here are the overwrites for lg styles.

While my markup simply had one class per element that was named properly and I knew just by the class name, what this element is supposed to be.

But when I see some div element with like 12 different rules, I might not know that right away what this element is supposed to do.
Also, in the inspector I just have one class with all the css rules which I can toggle on off nicely and debug my designs. But with the "recommended" approach, I'd have a long list of rules per class in each element when viewing the element in my inspector.

[wongjn]

In this case, I split class names up into multiple lines like:

<div
  class="
    px-2 md:px-4 lg:px-8
    …other classes…
  "
>

If you reuse this group a lot, you could refactor this string to a constant and use it elsewhere:

export const PX = 'px-2 md:px-4 lg:px-8';

<div class="{PX} …other classes…">

Or perhaps abstract it to a CSS variable:

<div class="[--px:--spacing(2)] md:[--px:--spacing(4)] lg:[--px:--spacing(8)]">
  …
  <!-- Some deep level component -->
  <div class="px-(--px)">

[tamerkalieh]

Yes. I guess I'll get used to the more modern approach. I'll reconfigure vscode so the css rules splitted into multiple lines won't be moved to one line again on save and go from there :D

Thanks for that! We done here