Tailwind purges non-tailwind classes

[jono-pov]

Hello!

I'm not posting this as an issue because I guess I'm not sure if the behaviour I'm seeing is expected or not.

My project uses Tailwind 3.4.4 as a PostCSS plugin, with a lot of custom styles in SCSS files. When I started on this project it was still using Tailwind 2, so there are a lot of /* purcgecss start ignore */ lines in the CSS. While I understand that v3 doesn't use PurgeCSS anymore, it still does seem to be actively removing class declarations from my custom CSS for things it can't find in the templates (as defined in config/content).

This is particularly annoying for components that use classes JS-generated classes, that don't necessarily appear in any of the templates. One prime example, and the big source of my confusion is the automatic classes added by Vue when you use a transition directive.

Example:
I have a Vue component that uses a transition called 'slide'. When the transition is triggered, Vue adds classes like .slide-enter-active or .slide-leave-to to the element. I wrote the definitions for those classes in a SCSS file, but because they don't appear in any templates, Tailwind removes them.

I didn't want to add a dozen individual classes to the safelist, so I created a regex matcher to cover them all:

safelist: [
    {
        // Ensure Vue transition classes are kept
        pattern: /(\w+)-(enter|leave)-(active|from|to)/,
    },
],

This works fine, but during my build process Tailwind started warning me about it:

[16:31:44] Starting 'compile:styles:build'...
warn - The safelist pattern `/(\w+)-(enter|leave)-(active|from|to)/` doesn't match any Tailwind CSS classes.
warn - Fix this pattern or remove it from your `safelist` configuration.
warn - https://tailwindcss.com/docs/content-configuration#safelisting-classes

The wording of that warning implies to me that the intention of Tailwind's CSS shaking is to ensure only Tailwind classes that are used are kept, and keep its grubby mitts off any non-Tailwind classes.

Another example is the Vue VCalendar component. The documentation for that component suggests one can create custom colour schemes like this:

<template>
    <VCalendar color="sky-blue" :attributes="attrs" />
</template>
<style>
    .vc-sky-blue {
        /* Custom styles here */
    }
</style>

Doing it this way, VCalendar adds the class vc-sky-blue to the elements it generates and expects you to write CSS to match. But because vc-sky-blue isn't found in my template, Tailwind removes it.

Another class I need to add to the safelist option that the Tailwind docs say should be a last resort.

Am I using this wrong. Is there a better approach to keeping my non-Tailwind classes intact? Or is Tailwind just being too greedy?

[wongjn]

I wrote the definitions for those classes in a SCSS file, but because they don't appear in any templates, Tailwind removes them.

Am I using this wrong. Is there a better approach to keeping my non-Tailwind classes intact? Or is Tailwind just being too greedy?

As per the documentation:

If you want to add some custom CSS that should always be included, add it to your stylesheet without using the @layer directive:

@tailwind base;
@tailwind components;

/* This will always be included in your compiled CSS */
.card {
  /* ... */
}

@tailwind utilities;

If you are already doing this with your transition class CSS rules, then it would seem like something else is removing the rules, not Tailwind.

[jono-pov]

Thanks @wongjn!

I had thought that something else might be the culprit; this is a large and unwieldy codebase that I came to very late and I'm still finding new surprises 😅. However, the fact that adding my rules to the Tailwind safelist causes them to stick around would seem to confirm that Tailwind is what's doing the removing.

Unfortunately these instances of custom code are nested deep inside imported SCSS files in my components directory, which is in a @layer:

// Components
@layer components {
	@import 'patterns/02-components/index';
}

I suppose based on that I could remove that import from the @layer, but that could have conflicts with the utilities @layer further down, and would seem to just go against the concept of using layers at all 🫤