Source detection and generated CSS

Tailwind does not need a handwritten CSS rule for every utility. It scans eligible source files for class tokens and generates CSS for the utilities it recognizes. This is why production builds can remain compact: unused utility classes are not generally emitted just because they exist in the framework.

A common mistake is constructing a class name dynamically:

const className = `bg-${color}-600`;

The complete class may not exist as a literal in the source, so source detection may not generate it. Prefer mapping application states to complete class strings:

const colors = { success: "bg-green-600", danger: "bg-red-600" };

This is also safer because only explicitly supported variants can be selected.

Avoid arbitrary runtime fragments

Do not assume Tailwind can infer every class produced by string concatenation. Keep class candidates statically visible or configure a supported source/safelist mechanism for your version.

Use complete class names

const statusClasses = {
  success: "bg-green-600 text-white",
  warning: "bg-amber-300 text-amber-950",
  danger: "bg-red-600 text-white",
};

export function StatusBadge({ status, children }) {
  const classes = statusClasses[status] ?? "bg-slate-200 text-slate-900";
  return <span className={`inline-flex rounded-full px-3 py-1 text-sm ${classes}`}>
    {children}
  </span>;
}

💡 Each possible utility appears as a complete string in the source. Tailwind can detect these candidates. The fallback also protects the UI when an unexpected status value arrives. In TypeScript, define status as a union such as "success" | "warning" | "danger" for stronger guarantees.

Knowledge Check

Why can `bg-${color}-600` fail in a production build?

Source detection and generated CSS

STAY UPDATED WITH BYTES!