Safelist alternative

[ic-768]

My company's app has an integrated component library, that creates classes programmatically, like so:

active:border-${color}-${colorIntensity},
isActive && `border-${color}-${colorIntensity}

We used to be able to safelist all of these, by providing a regex pattern to safelist, e.g.:

    {
      pattern:
        /border-(zinc|red|amber|lime|emerald|sky|blue|violet)-(50|100|200|300|400|500|600|700|800|900|950)\/(50)$/,
      variants: ["hover", "active"],
    },

Now with the safelist not supported in v4, the only solution I can find for cases like these is manually inputting all the classes in a text file so that they can be parsed. Needless to say, I'd rather not do that.

Is there any other solutions for cases like this?

[Skoua]

A workaround could be to list all classes in a unused file and source it like so:

@source "./safelist.css";

[ic-768]

Sure, but unfortunately not very efficient when you're dealing with hundreds of permutations of different properties and values.

[jpgnz]

https://x.com/adamwathan/status/1882760975201579135

This is the suggestion from @adamwathan as well.

My use case is a single vue component that is reused in a lot of places with different content (a drop down list) that is getting classes as part of a response, so I'm maintaining a long text file now rather than a few lines of regex.

[landykos]

@ic-768 Our solve for this was to create a JS file that creates all the safelist classes and outputs them into a txt file that is in our theme code that tailwind watches during our build process. Not ideal but it works better then typing out all the permutations.

Used an array to mimic the pattern style.

[landykos]

Also we did this for theme vars as well ;)

[quantikaSRL]

My company's app has an integrated component library, that creates classes programmatically, like so:

active:border-${color}-${colorIntensity},
isActive && `border-${color}-${colorIntensity}

We used to be able to safelist all of these, by providing a regex pattern to safelist, e.g.:

    {
      pattern:
        /border-(zinc|red|amber|lime|emerald|sky|blue|violet)-(50|100|200|300|400|500|600|700|800|900|950)\/(50)$/,
      variants: ["hover", "active"],
    },

Now with the safelist not supported in v4, the only solution I can find for cases like these is manually inputting all the classes in a text file so that they can be parsed. Needless to say, I'd rather not do that.

Is there any other solutions for cases like this?

Not sure if this fits your needs, but we’ve created a Rust script that, in development mode, opens a WebSocket and receives dynamically generated class names, which it writes into a .txt file that Tailwind can read. Here's a rough overview of the workflow:

Workflow

0. When running a project locally, we execute a Rust script that opens a WebSocket.
1. We detect the development environment via process.env.MODE, and use a Vite plugin (most of our projects are built with Vue) to establish a WebSocket connection.
2. In our .tsx components, we hook into functions that generate dynamic class names and send the resulting output through the WebSocket, so the Rust script can write them into the .txt file.

This allows us to completely remove the need for Tailwind's safelist — we've tested it successfully in both Tailwind v3 and the latest v4.

---

Known Issues / Odd Behaviors

1. When a component is mounted, if the changes in the .txt file are too large, the page sometimes refreshes unexpectedly. This only happens in development mode, since production CSS is already compiled.
2. We're currently trying to improve the build process. We reset the .txt file before each build to eliminate unused or stale class names (e.g., if you added a component with dynamic classes and later deleted it). Because of this, we should ideally mount all components and pages during the build to ensure all required classes are listed. Still looking for a better solution here.

---

Pros of This Approach

• No need to maintain a safelist.
• Significantly reduces final CSS size (ours went from ~11 MB down to ~50 KB).

[leon-plackal]

A solution I had used in a similar situation to yours (a component library where classes can be typed and displayed live) was actually to use the Tailwind CDN. This seemed like one of those times it was good use case for the CDN, if viable for your app. I originally used your method of having a text file with as many classes as possible, but this was very tough to maintain for obvious reasons and missed many variations.

What I did was dynamically load the CDN script only on the pages that needed them. This worked really well for me and also avoided a lot of the headache.

[CanRau]

There's now @source inline("underline")
docs

more discussions with examples

[jpgnz]

Thank you for posting @CanRau !