Add built-in Tailwind class formatter support

[leaked]

First of all, thanks for maintaining the Phoenix Tailwind package.

I would like to suggest adding optional Tailwind class formatting/sorting support to the package.

Currently, the package provides excellent editor integration, but formatting and consistent ordering of Tailwind classes still require external tooling. It would be very useful if the extension could optionally sort and format Tailwind utility classes automatically.

A good example of this approach is:
canonical_tailwind

Having this functionality built directly into the official package could provide several benefits:

• Consistent Tailwind class ordering across Phoenix projects
• Better out-of-the-box developer experience
• Reduced dependency on additional editor extensions or external tools
• Easier onboarding for new Phoenix developers

Ideally, this could be optional/configurable so users who already use other formatting tools can keep their existing workflow.

Thanks again for the great work on the package.

[leaked]

cc @aptinio — you may already have useful experience around this from canonical_tailwind.

[aptinio]

Thanks for the ping, @leaked.

A couple of thoughts:

tailwind and canonical_tailwind solve different problems. tailwind installs the Tailwind CSS CLI and gives you a streamlined way to run it. canonical_tailwind plugs into Phoenix.LiveView.HTMLFormatter's attribute_formatters hook to canonicalize classes in HEEx during mix format. Keeping them in separate packages has worked out nicely, and each evolves independently.

I'm with you on the out-of-the-box experience though. One path: a "blessing" from the Phoenix team, e.g. having mix phx.new add canonical_tailwind to .formatter.exs by default. New projects would get sorted classes from day one, without conflating asset compilation and code formatting at the package level.

[josevalim]

If we want to include it in Phoenix, then I'd prefer to have it bundled in, so we have fewer dependencies emitted in new apps out of the box. I'd like to test it out in a large project so I understand the costs better (basically how it may affect formatting performance).

On the other hand, another argument to keep it separate is that in the future we may have alternative ways of implementing this, such as via Rust integration, which could be faster than via I/O but then it would not be consistent with this project.

[aptinio]

Thanks for engaging with this, José.

On performance: canonical_tailwind runs the Tailwind CLI with --stream, keeping a pool of persistent port processes across the entire mix format run — not spawning one per attribute or file. That's about as lean as it gets given the current architecture.

On the Rust angle: I had a look at the tailwindcss repo — the Rust crates (oxide, node) are the scanner/extractor for finding class names in source files. The canonicalization logic itself (canonicalize-candidates.ts) is still TypeScript. So a Rust-based alternative isn't really a near-term path for this specific operation.