schoero/eslint-plugin-better-tailwindcss

ESLint plugin to automatically break up long tailwind class strings into multiple lines for better readability.

Summary

eslint-plugin-better-tailwindcss is an ESLint and Oxlint plugin that improves Tailwind CSS code through formatting rules (sorting, line wrapping) and linting rules (catching unknown or conflicting classes). It supports React, Solid.js, Qwik, Svelte, Vue, Astro, Angular, HTML, and plain JavaScript or TypeScript projects. The plugin is written in TypeScript and is published under the MIT license.

What it is useful for

This plugin helps teams that use Tailwind CSS keep class strings readable, consistent, and valid as a project grows. The formatting rules break long class lists across lines, sort classes and variants in a predictable order, replace verbose class names with shorthand equivalents, and remove duplicate or deprecated classes. The correctness rules flag issues that would otherwise surface only at runtime or in the browser, such as classes that Tailwind does not recognize (no-unknown-classes), classes that produce conflicting styles (no-conflicting-classes), and concatenated class strings that Tailwind cannot analyze (no-concatenated-classes).

The plugin comes pre-configured to recognize common class-combining utilities, including clsx, cn (shadcn), twMerge/twJoin (tailwind-merge), cva (class-variance-authority), tv (tailwind-variants), cc (classcat), clb (class-list-builder), cnb (cnbuilder), ctl (classnames-template-literals), objstr (obj-str), and twc/twx (react-twc), so most setups work without extra wiring. It also supports Tailwind CSS v3 and v4, though some rules are only available for v4 (for example, enforce-consistent-variant-order, enforce-canonical-classes, and no-conflicting-classes).

How engineers can use it

According to the README, installation is a single dev dependency:

npm i -D eslint-plugin-better-tailwindcss

Framework-specific parsers must be installed separately. The README links to per-framework guides (JSX, TSX, Svelte, Vue, Astro, Angular, HTML, CSS, JavaScript, TypeScript), so the exact parser configuration depends on the framework you use.

In your flat config, you can enable one of three recommended configs:

• stylistic: stylistic rules only, reported as warnings by default
• correctness: correctness rules only, reported as errors by default
• recommended: both, with stylistic as warnings and correctness as errors

Severity can be overridden with suffixes such as recommended-warn or stylistic-error. For legacy .eslintrc users, the plugin provides legacy-recommended and legacy-correctness-warn configs.

In monorepos where Tailwind is configured per package, the README documents setting settings["better-tailwindcss"].cwd per file group in eslint.config.js so the plugin resolves the right Tailwind project root. For VSCode, enabling editor.codeActionsOnSave with source.fixAll.eslint (or source.fixAll.oxc for Oxlint) applies autofixes for most rules on save.

Documented limitations: a few rules (no-concatenated-classes, no-unknown-classes, no-conflicting-classes, no-restricted-classes) do not autofix, and Tailwind v4 is required for the variant-order, canonical, deprecated, and conflicting-classes rules. The README does not specify minimum Node, ESLint, or Tailwind versions, so readers should consult the linked parser docs and the advanced configuration guide for details on custom attributes, callees, variables, and tags.