Tailwind CSS v3 JIT omits dynamically constructed utility classes

Direct Answer

No, Tailwind CSS v3 does not provide a built-in JIT configuration that automatically captures arbitrarily constructed utility strings (e.g., bg-${color}-500) without either writing the complete class names statically in source files or explicitly safelisting them. The regex-based content scanner only detects full utility strings present in the scanned files at build time.

Confirmed Behavior

• The v3 JIT compiler extracts class names via static regex patterns against the content globs; template literals, string concatenation, and runtime variables are opaque to this scanner.
• The safelist option in tailwind.config.js accepts exact strings, arrays, or regex patterns (e.g., { pattern: /bg-(red|blue)-500/ }), but broad patterns like bg-* pull in every matching utility and inflate the production CSS bundle.
• Third-party AST-based scanning plugins exist for v3, but they are community-maintained, not officially supported, and may break across minor Tailwind releases.
• Writing utility classes as complete, static strings in your templates/JSX remains the only zero-configuration, future-proof way to guarantee inclusion.

Recommended Production Approach

1. Prefer static class strings. Refactor dynamic constructions into explicit class lists where feasible (e.g., use a mapping object that returns full class names).
2. If dynamic patterns are unavoidable, use a narrow regex safelist. Example:

   // tailwind.config.js
   module.exports = {
     safelist: [
       { pattern: /bg-(red|green|blue)-(100|500|900)/ },
       { pattern: /text-(sm|base|lg)/ }
     ],
     // ...
   };

   This limits bundle growth to only the variants you actually use.
3. Verify the output. After a production build (NODE_ENV=production npx tailwindcss -o output.css), search the generated CSS for the expected utilities. Missing classes indicate a safelist gap.

When to Consider Third-Party AST Scanners

Only if you have a large, stable codebase with extensive dynamic class generation that cannot be refactored, and you are willing to pin the plugin version and test after every Tailwind minor upgrade. Treat them as a temporary bridge, not a long-term solution.

One Diagnostic Detail Needed

What is the approximate number of distinct dynamic class permutations your application generates at runtime? (e.g., tens, hundreds, thousands) This determines whether a narrow safelist is practical or if a refactor to static strings is the only scalable path.