esbuild-plugin-pipe VS posthtml

ESBuild’s author and docs[1] are quite clear about its future scope:

> [… a list of features that are already done…]

> After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers.

That said, now quoting you…

> But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about.

In this respect, ESBuild’s firm stance has a major strength, and a major weakness:

- Strength: the Unix philosophy is easy to achieve, with esbuild-plugin-pipe[2]. There’s just one, simple plugin API, everything follows that same format

- Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool

1: https://esbuild.github.io/faq/#upcoming-roadmap

2: https://github.com/nativew/esbuild-plugin-pipe

A bundler running an html transformer like https://github.com/posthtml/posthtml could do this. Then the html would just be dependent on an environment variable to set your prefix conditions.

This uses PostHTML to convert the tailwind classes into inline styles, but it could maybe be adapted to generate CSS files instead, but seriously, this largely defeats the purpose for using tailwind.