eslint-plugin-better-tailwindcss sorts your class strings in the lint step

Class ordering treated as a lintable problem

The premise of the plugin is that Tailwind class strings are code, and code can be checked and rewritten. The README describes it as a plugin with formatting and linting rules to help you write cleaner, more maintainable Tailwind CSS, and the package description is blunter, saying it auto-wraps tailwind classes after a certain print width or class count into multiple lines to improve readability. So the class attribute is not treated as an opaque string. A long list of utilities is a sequence with a natural order, and a long line is a formatting problem. The plugin takes both claims and makes them into rules, which means the result is committed code rather than a preference that depends on whoever typed the class list last.

Two rule families and three named configs

The rules are split into two types, `stylistic` and `correctness`, and the plugin offers three recommended configurations to get started. The `stylistic` config enforces the stylistic rules for tailwind classes, and the `correctness` config enforces the correctness rules. The third, `recommended`, is the combination, and the README's description of it is cut off mid-sentence in the version of the documentation available here, so the exact membership of that preset is something you confirm in the source rather than assume. The package entry point reflects the same split, since the main export is the config module at `./lib/configs/config.js`, with separate exports for defaults and for types under `./api/defaults` and `./api/types`.

A parser for every flavour, documented separately

Because the plugin has to read your class strings out of the file, it needs the parser for that file type, and the quick start spells out one parser per framework with its own documentation page under `docs/parsers/`. React, SolidJS and Qwik share the `.jsx` and `.tsx` pages, Svelte has its own `.svelte` page, Vue has `.vue`, Astro has `.astro`, Angular has an `.html` and `.ts` page, plain HTML has `.html`, CSS has `.css`, JavaScript has `.js` and TypeScript has `.ts`. The README states the plugin supports a wide range of projects, including React, Solid.js, Qwik, Svelte, Vue, Astro, Angular, HTML or plain JavaScript or TypeScript. The setup cost is that each flavour in your repository needs its parser configured, which is a real but bounded amount of configuration.

Installing the plugin and wiring it into the lint run

The install is a single dev dependency:

npm i -D eslint-plugin-better-tailwindcss

After that, the plugin is configured the way any ESLint plugin is, and the README points at the parser documentation for your flavour before the rules are turned on. The plugin is written in TypeScript and published as an ES module, since the package sets `"type": "module"` and the build output is produced by `vite-node build` into `lib/`. The repository also ships an `eslint.config.ts` at the root, so the project dogfoods flat config on itself, and the `docs/` tree is the documentation source. The plugin is described as working with ESLint and Oxlint, which matters for teams that have already moved one of their linters across.

The scripts that show how the project is maintained

The package scripts are a decent map of the project's own workflow. There is a `bench` script that runs `vitest bench` against a separate `vite.config.bench.ts`, so the rule performance is measured inside the repository rather than asserted. There are parallel lint scripts for the plugin's own source, with a `lint:ci` variant that adds `--max-warnings 0`, and a markdownlint setup that checks Markdown files and skips node_modules. Two convenience scripts install Tailwind v3 or Tailwind v4 with `--no-save`, which suggests the rules are exercised against both major versions of the framework rather than only the newest. There are also `postrelease` scripts that fix up `package.json` and the changelog after a release, and a `changelog.config.js` that drives the changelog generation, alongside an `AGENTS.md` and a `.cspell.json`.

The alternative of no enforcement at all

The realistic alternative is not another plugin but the status quo, where class order is whatever the author typed, or whatever the editor's Tailwind extension happened to rewrite, and where a class that does not exist is discovered when the element renders without it. The difference in approach is where the correction happens. Hand sorting happens at the moment of writing, in whichever editor the author happens to use, and it is not reviewed. A lint rule happens at review time and in continuous integration, on every file, with the same result on a laptop and on the build server. The cost is that the plugin takes over formatting of class strings, so if you currently rely on a different tool to rewrite them, the two will fight, and the README does not document how it interacts with an external formatter.

MIT licensed and moving quickly through the 4.x line

The licence is MIT, held by Roger Schönbächler, which in short terms means you can use, modify and redistribute it with the notice preserved. The release cadence is the notable thing. Version 4.10.0 was published on 2026-10-19, followed by 4.9.1 on 2026-10-13 and 4.9.0 on 2026-10-05, and the repository is not archived with the last push on 2026-10-19. Three releases in two weeks is a fast pace for a lint plugin, and it has an obvious effect on how you should adopt it. Pinning an exact version is reasonable, and a plugin that changes formatting behaviour under you will show up as diff noise in a pull request if the version is allowed to float. The repository keeps a CHANGELOG, a CONTRIBUTING guide, tests, a `build/` directory and an `assets/` folder, so the project is set up for outside contributions as well as frequent internal ones.

Editorial conclusion

Adopt eslint-plugin-better-tailwindcss when class ordering and class validity should be enforced by the same tool that already runs in your lint pipeline, since the plugin ships formatting rules and correctness rules and works under both ESLint and Oxlint. Do not adopt it as a way to learn which Tailwind classes exist, because the correctness rules report problems rather than complete a class list for you. Verify first which parser your framework needs, since the quick start requires a matching parser for each flavour, and note that the project ships Tailwind v3 and v4 install scripts, so check which major version your codebase is on before enabling the recommended config.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. schoero/eslint-plugin-better-tailwindcss on GitHub