no-deprecated-classes

oxlint rule that rewrites Tailwind CSS classes renamed in v4, like flex-grow → grow and bg-gradient-to-r → bg-linear-to-r, with an autofix.

At a glance

Autofix	Editor suggestions	Design system	Options
Yes	Yes	Optional — used when entryPoint is set	entryPoint

What this rule does

Flags any class that was renamed when Tailwind moved from v3 to v4 and rewrites it in place with an auto-fix. Examples: flex-grow → grow, flex-shrink → shrink, overflow-ellipsis → text-ellipsis, decoration-clone → box-decoration-clone, bg-gradient-to-r → bg-linear-to-r (and the rest of the gradient directions). Variants and ! (important) modifiers are preserved on both sides of the rewrite.

Where the rename list comes from

With settings.tailwindcss.entryPoint (or the rule's own entryPoint) configured, the list is derived from your design system: Tailwind's own canonicalizeCandidates is asked what each v3 spelling maps to, and only the ones it still compiles AND still renames are reported. That covers renames a hardcoded table did not — break-words → wrap-break-word, order-none → order-0, the reordered position spellings bg-left-top → bg-top-left and object-left-top → object-top-left — and, more importantly, an entry disappears by itself when a future Tailwind stops compiling it, instead of suggesting a replacement for a class that no longer exists.

Without an entry point the rule falls back to a hardcoded table of the 15 best-known renames, so it still works with nothing configured and never emits a designSystemUnavailable diagnostic.

Options

entryPoint

string, optional. A CSS entry point for this rule alone, overriding settings.tailwindcss.entryPoint. Used to derive the rename list; the rule works without it.

Examples

✗ Incorrect

// v3 flex aliases — v4 dropped the `flex-` prefix
<div className="flex-grow flex-shrink-0" />
// → <div className="grow shrink-0" />

// Gradient direction — renamed to bg-linear-to-*
<div className="bg-gradient-to-r from-blue-500 to-purple-500" />
// → <div className="bg-linear-to-r from-blue-500 to-purple-500" />

// Text overflow alias and box-decoration shorthand
<div className="overflow-ellipsis" />
// → <div className="text-ellipsis" />
<div className="decoration-clone" />
// → <div className="box-decoration-clone" />

// Variants and important are preserved on the way out
<div className="hover:!flex-grow" />
// → <div className="hover:!grow" />

✓ Correct

// Post-migration spellings
<div className="grow shrink-0" />

<div className="bg-linear-to-r from-blue-500 to-purple-500" />

<div className="text-ellipsis" />
<div className="box-decoration-clone" />

<div className="hover:!grow" />

Interactions with other rules

• no-unknown-classes: silently skips any renamed spelling, asking the design system rather than a list of its own, so the two rules cannot disagree. You won't get "unknown class" plus "deprecated class" for flex-grow — only the deprecation. Keep both rules on.
• enforce-canonical: this rule owns the renames. Tailwind canonicalizes them too (bg-gradient-to-r → bg-linear-to-r is both a deprecation and a canonicalization), so both rules used to report the same class with the same fix. enforce-canonical now stays quiet about anything in the rename list and keeps the rest: valid-but-non-canonical forms like -m-0 → m-0 and start-2 → inset-s-2 (start-* is current Tailwind, just not the canonical spelling). Keep both on — with only enforce-canonical enabled the renames go unreported.
• no-restricted-classes: orthogonal. Use that one to ban valid classes; this one only triggers on the fixed v3→v4 rename list.

When to disable it

• You're still on Tailwind v3 and want to keep the v3 spellings. Disable this rule until you migrate.
• You intentionally ship a v3-compatible class layer alongside v4 (for example, a shared library that targets both). In that case prefer a targeted eslint-disable on the file rather than a project-wide disable.