Replies: 1 comment
-
|
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.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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