eslint-plugin-tailwind-design-tokens

The problem

A design system defines a finite color palette as tokens — --color-ink, bg-primary, text-soft-green. But nothing stops a raw #0a0a0a, an rgb(10 10 10), or a stock text-red-500 from sneaking into a component, and every one quietly erodes the system.

This plugin catches them at lint time. When a hardcoded value matches one of your tokens, it tells you exactly which token to use instead — and the fix is automatic.

Before / after

// ✗ flagged — stock palette class + hardcoded hex
<button className="bg-[#0a0a0a] text-red-500" />

// ✓ design-system tokens
// (when #0a0a0a maps to a token, bg-[#0a0a0a] → bg-ink is auto-fixable)
<button className="bg-ink text-primary" />

How it works

• no-hardcoded-colors scans every string and template literal for color values, normalizes each (so #FFF matches #ffffff), and looks it up in your token map. Hex plus rgb/hsl/hwb/lab/lch/oklab/oklch are all detected — including inside arbitrary values like bg-[#0a0a0a].
• no-default-palette splits class strings and flags any default Tailwind palette utility (prefix-family-shade), tolerating important (!) and opacity (/50) modifiers.

It understands where tokens live across Tailwind versions — a v4 @theme block, a v3 tailwind.config.js, or an inline map — so it works whatever your setup. Token files are read once and cached per ESLint process, invalidated by file mtime.

Engineering notes

Supports ESLint 9+ with both flat and legacy config systems. Every release is published from CI with npm provenance attestations.