Replies: 3 comments
-
|
I went looking for who else might benefit from this and found the same pattern across ecosystems: tools either re-implement the sort order and drift from it, or depend on Node.js/Prettier in ecosystems that don't otherwise use them. A few examples:
The implementation is small — a readline loop around the existing design system. |
Beta Was this translation helpful? Give feedback.
-
|
This would actually be very useful outside the JavaScript ecosystem. Right now most tools that try to sort Tailwind classes end up either re-implementing the ordering logic or parsing compiled CSS, which tends to drift from the official sort order over time. Having an official CLI command that exposes the same sorting logic used by the Prettier plugin would make things much more consistent. It would also make it easier for tooling in other ecosystems (like template formatters or editor plugins) to support Tailwind class sorting without needing to depend on Node.js or embed JS tooling. If the implementation really can reuse the existing design system logic, a small CLI wrapper around it sounds like a clean and maintainable approach. |
Beta Was this translation helpful? Give feedback.
-
|
Related: in discussion #19092, @Princesseuh asked about running the CLI as a persistent process for a Rust-based static site generator, and @philipp-spiess replied:
This proposal is a small step in that direction — exposing one specific design system capability (class sorting) over stdin/stdout so non-JS tools don't need to embed Node or reimplement the logic. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The design system knows how to sort classes, but there's no way to access that outside JavaScript. The Prettier plugin uses the sorting API directly — non-JS tools have to reimplement sorting by parsing compiled CSS output instead.
A CLI subcommand would close that gap:
It loads the design system once, then reads class lists from stdin and writes sorted results to stdout, one per line, until stdin closes. Sorting semantics match the Prettier plugin: unknown classes stay at the front in their original order, known classes sort by canonical position, and duplicate known classes are removed.
This would benefit ecosystems the Prettier plugin doesn't reach — Elixir/HEEx, Ruby/ERB, Go templates, Python/Jinja2 — as well as editor plugins that don't want a Node.js dependency (e.g. a Neovim plugin using treesitter to find class attributes).
I'm building tw_sort, an Elixir library that sorts Tailwind classes in HEEx templates via
mix format. It currently parses CSS output to determine ordering. I'd be happy to contribute a working implementation — I have one on a fork with unit and integration tests.Beta Was this translation helpful? Give feedback.
All reactions