dev mode option to run with the complete tailwind build

[rubydesign]

As per title, no problem here, tailwind works great and the gem too. As it is designed.

But i find during development, it is a whole lot faster to prototype in the browser.
Using the development tool (inspector) i add/remove/modify classes in the browser until i am happy and then copy the result into the template. Have another look and move on.
This saves all the reloads and while that may not sound a lot, it adds up. The approach is in line with tailwind i find, and actually got the idea from a video Sam Selikoff, emberconf.

Off course for this to work, one needs the complete tailwind build (300k), so the classes are actually available.

I know i can (and do) achieve this quite easily with an if and the cdn. But i though it would be nice if it were integrated and documented as an at least alternative workflow. If it were integrated, tailwind configuration changes/additions would also be available.

[ifasoldt]

Ha, came here to leave the exact same comment

[flavorjones]

Unfortunately, tailwindcss (the upstream project, not this gem) only supports JIT mode in v3. Here's the creator's explanation:

tailwindlabs/tailwindcss#6256 (reply in thread)

Specifically he says:

Tailwind CSS v3+ will always be JIT-only. ... Hopefully this doesn't come across as dismissive — I've tried my best to offer several solutions here, but ... we don't plan to invest in any non-JIT workflows going forward

He also suggests a potential workaround:

Maintain your own safelist. You can use your current CSS file as a starting point if you wanted to, extract all the classes, and format those into a safelist and be in a decent spot. It would be missing all of the new Tailwind 3 default colors, new utilities like caret-color, etc., but you could add in whatever you need.

but he warns:

The issue is that even with a safelist as simple as this:

safelist: [
 {
   pattern: /./,
   variants: ['hover','focus','sm','md'],
 },
]

... the generated CSS is 4.6mb

This seems like a very different result from @rubydesign's statement above that the payload would only be ~300k. 🤷

Unless I'm missing something, I don't think there's anything this gem can do to workaround this guiding principle in the upstream Tailwind CSS project. I'd be happy to learn that I'm mistaken, though, so please tell me if there's a specific approach you'd like to take (maybe in a PR?)!