There is a safelist, and it is the right answer in exactly one situation: the class genuinely is not known until runtime — a colour stored in a database, a value from an API, something a user picks.
In that case no amount of writing classes out helps, because the value does not exist at build time. You list the possible classes in the config and they are generated regardless of whether they were found in source.
Why it is a last resort rather than a general fix:
- It generates CSS you may not use, which is how a stylesheet quietly grows
- It is a second place to maintain. Add a variant to the component and forget the safelist, and you are back to unstyled elements with a fix that looks like it should have worked
- It hides the mistake rather than correcting it, so the next person copies the pattern
If you do need it, keep it small and specific — enumerate the classes rather than reaching for broad patterns, because a pattern generates a lot more than you think.
For the genuinely dynamic case there is often a better option: put the value in a CSS custom property and set it as an inline style, and keep the utility classes static. A colour that comes from a database is data, and data belongs in a style attribute rather than in a class name you have to predict at build time.