"Old" build/compilation mode for Tailwind 3

[waj00115]

I know for Tailwind 3, JIT is the default mode, but is it the only mode?

Is there a way to change this to the old method of having what I realize will be an absolutely massive file for Tailwind 3? Perhaps in the config file with mode: "something" as there was mode: "jit" in Tailwind 2? Or is the mode option completely removed with no alternative.

It appears if you don't set the watch option, it requires that there be a content path specified and automatically autopurges, and if you don't specify content, it results in what appears to be basically just the normalize/reset stylesheet.

The reason I ask is I teach web development courses (HTML, CSS, and JS) at a community college. I use Tailwind not only to teach the students how to build websites using the framework, but I also use it as an opportunity to dig through Tailwind's CSS file to show teach them some of the more advanced CSS utilities that most frameworks don't implement, as well as all of the variants. (I'm not a fan of just saying "use this" without the how/why it works.)

If not, no worries -- I suppose from my understanding of how Tailwind does the purging (unless that has also changed) is it just keeps any class that is found as a string of text anywhere in the text file, and not just a class name on an HTML tag, and I can build a text file that lists all of the classes I want to go through and generate a CSS file from that, but particularly with the new variants being added, that may be a bit challenging to hit on everything.

[adamwathan]

Hey! v3 is JIT-only, so no way to generate the whole stylesheet I'm afraid. It would be several hundreds of megabytes with everything that is enabled/configured in v3 out of the box 😵‍💫

The only way to really pre-generate a more complete CSS file is by feeding Tailwind a complete list of class names you want included I'm afraid. Maybe a bit easier with pattern-based safelisting at least:

#5511

[waj00115]

I understand -- I guess I didn't compute in my head with how many new variants you added how big it would blow up.

For now, I've just created a shell script with a few loops in it to generate a list of classes to generate sort of a dummy file. It doesn't have everything but hits a variety of different way CSS selectors can be generated to get my point across.

[camslice]

The resulting stylesheet is not several hundreds of megabytes, it's only about 18MB for Tailwind v3. Just use a permissive safelist in development as demonstrated here and here

[sasial-dev]

You could use the tailwind CDN for this!

[sasial-dev]

^^ Just being aware there may be a very slight delay due to the fact it uses a MutationObserver.

[mohamadaliakbari]

but I need both full css file (like cdn version) and my custom classes like bg-[#000000].
So I need a mode to have all classes + what i have in my html file.

[thaoms]

This is also a big issue for us. We have our utilities living in a separate repo and package that is being used by multiple of our other repos. We have no context of which templates to use there. That means we can never update without doing huge changes in our codebase. Am I missing something? I think it's a weird decision to go full-jit mode and assume how people would or should work, not really a 'minor' breaking change like they claim..

Wouldn't hurt to have a non-jit mode, I mean we tinkered our configuration a lot over time for this.
Or will we get still some new css features for v2? Couldn't really find a roadmap for v2.

[lauthieb]

Thanks @leeshadle, this will help us!
Yes unfortunately it's hard, and I'm afraid to lost some CSS classes already used by our consumers but I'll have a look, thx!

[adamwathan]

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, which is getting close to the threshold where it's going to cripple the browser, and is just a ridiculous payload to be sending to every visitor.

Using this config:

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

...the generated file size is 8.9mb. And that's nowhere close to a true "full build" because of how flexible things are in Tailwind 3. It's missing tons of variants, and doesn't even include all of the breakpoints.

For example, this is a totally valid class in Tailwind 3:

<div class="dark:lg:group-hover:focus:active:required:bg-blue-300">

I don't think anyone would expect that to be included in a static build, but where do you draw the line you know? Trying to curate that balance was the biggest challenge in maintaining v2, and it meant a really bad developer experience because you had to constantly be managing variants, deal with painfully slow build times when integrating with tools like webpack, and if the file size got big enough it would make browser dev tools unresponsive or even crash.

So there's really nothing we can do here without throwing away all of the power of Tailwind 3 and reverting back to the handcuffed approach we had with v2.

Your best bets if you need to product a large unpurged CSS file:

1. 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.

2. Keep using Tailwind 2. Tailwind 2 is still great and will be the last version to support any sort of unpurged build out of the box. It means less features but that's the only way to keep the file size reasonable.

In general I would highly recommend against shipping a large unpurged CSS file to your users. It causes performance issues in the browser and uses a lot of unnecessary bandwidth. If you really need to do this, I personally think manually crafting a safelist is the best bet because it gives you fine-grained control over everything that will be included.

Here is an example safelist I made by just spending 10 minutes editing the output of the v2 CDN CSS file:

https://gist.githubusercontent.com/adamwathan/e44afadc1471f0b9f6afdde43b2b2f0a/raw/ef5a30393e9db3a7a33dd5c7c027b0f9307a3a52/v2-safelist.txt

(I messed up in my editing and deleted the group-hover variants, but it's Christmas break, can't spend more than 10 minutes on this sorry.)

Just as a final comment on all of this though, Tailwind CSS v3+ will always be JIT-only. Personally I would really recommend revisiting any scenarios where you've relied on the unpurged CSS in the past and figuring out a way to serve a JIT build, even if it means safelisting a few things that are used by content stored in a database or something like that. It's really a much better experience with a more better output.

If you absolutely cannot work that way, Tailwind 2 is still available, and since it's MIT licensed you can of course fork it and modify it however you need to should changes ever be necessary to make it compatible with Node v37 or something years down the road.

Hopefully this doesn't come across as dismissive — I've tried my best to offer several solutions here, but we are a small team working on this stuff for free and we don't plan to invest in any non-JIT workflows going forward.

[lauthieb]

Thanks a lot @adamwathan for this detailed answer and your investigations.
I understand all the things you mentioned and I also understand the benefits of switching to JIT mode.
After reflexion, I think we will prefer to stay in Tailwind v2 for our V0.x.x libraries but we will transition to Tailwind v3 for all our packages in V1.x.x.
Thank you very much again for all this great work for the community. ❤️

[henrikbjorn]

@adamwathan We also need the full file. We generate the .css based on our configuration and ship that as a RubyGem that is used by our main application.

The Application is older and uses the old Sprockets API. So adding JS to it, is not an option. So we ship a large css and then Sprocket does the purging when assets are build and we then have a small .css file for our users.

[adamwathan]

@henrikbjorn See my response above, we will not be pursuing a non-JIT version of Tailwind in the future. We have a standalone CLI build you can use if you can't use JS, this is what Rails uses by default:

https://tailwindcss.com/blog/standalone-cli

[blackjak231]

If anyone is looking for an alternative to the tailwind config solution during development, BeyondCode just released their new tool for browser testing which inserts ALL tailwind classes for development. Please note that this is a paid solution !

Check it out here : https://devtoolsfortailwind.com

[GiorgioG]

I can understand the reasoning behind not wanting to maintain multiple modes, but it also hurts discoverability (IDEs can't add completions for classes that don't exist.) Unless there's a workaround that I'm not aware of. FWIW I am a paying TailwindUI customer.

[LionsAd]

@adamwathan

Unfortunately you kind of killed in-browser template editing with that - especially for eG PHP projects.

I was using custom purging and class generation from a JSON file to insert only the classes needed but without the JIT.

Unfortunately the JIT is JS and not a custom declaration language - even though 95% of plugins are super simple, which makes it hard to run in eg PHP or Python backends. (That would be ideal)

Fortunately there is a way to still get all classes via the new generation mechanism for those looking here:

#6347 (comment)

via the patterns.

So I can continue to use that for the final production dynamic build at least.

Identifying TW-classes in final HTML output is super simple using a tree structure btw.

I can see it’s bad for the in-browser class adding feature though to load MBs of HTML.

Probably the best would be to run the JIT inside of the browser in that case via a DOM mutation observer.

I’ll explore more 👍.

edit: Did not see your threaded response - fully understood.

Would you be open to do JIT in a different way - where JIT-Engine can be implemented in PHP, Ruby, Python, …?

[alexizzz0]

This is perfect for testing code when you're trying to dev a project that is backend heavy like a laravel project where the front end needs to look clean and elegant but the focus is on the backend PHP. The IDE can now autocomplete those clases and when you are done take it out and let tailwind do its thing. GREAT IDEA.

There should be a logical on and off button tho. Not every dev out there is a frontend dev. As a full stack dev I need all my tools at the ready. I don't need to spend time figuring out the best fit for something by compiling and recompiling code. Just bake it and then when I'm done throw away the trash you didn't use.

[bostondevin]

Yeah - this is a huge pain in the bum if we're building screens dynamically - now i'm just safelisting every class that I could ever use... Does anyone have a tailwind config that safelists everything with patterns? I need dark mode and opacity too - Here's my start:

safelist: [
    {
      pattern:
        /bg-(slate|zinc|stone|red|orange|amber|yellow|lime|green|emerald|teal|cyan|sky|blue|indigo|violet|purple|fuchia|pink|rose)-(100|200|300|400|500|600|700|800|900)/,
      pattern:
        /outline-(slate|zinc|stone|red|orange|amber|yellow|lime|green|emerald|teal|cyan|sky|blue|indigo|violet|purple|fuchia|pink|rose)-(100|200|300|400|500|600|700|800|900)/,
      pattern:
        /text-(slate|zinc|stone|red|orange|amber|yellow|lime|green|emerald|teal|cyan|sky|blue|indigo|violet|purple|fuchia|pink|rose)-(100|200|300|400|500|600|700|800|900)/,
    },
  ],

What I really want is some utility function that I can feed in a list of classNames and it pulls in the classes on-demand instead of this ugly bloated approach...

[GiorgioG]

I'm working on a microfrontend architecture at work - multiple SPAs are distributed in multiple repos and loaded separately at runtime. We can't simply maintain a shared whitelist. Using the CDN won't work for us because we need to make customizations to the configuration. We're still in early days and our team doesn't want to switch to another CSS framework, but if we can't find a way around this we may be forced to.

[LionsAd]

@GiorgioG there is always Tailwind v2 and it works perfectly for now.

That said we switched to a hybrid solution of hosted CDN and whitelisting classes.

EG any class entered is retrieved from the browser and stored in the DB, a middleware is dynamically injecting the utilities styles.

To do that I generated a heuristic to detect Tailwind classes on the rendered page and then checking if they are in a utilities.json (CSS to JSON structure) and only show those that are needed.

The CDN is used for any fallback, but we are working to self-host a version and just have the middleware tell the JS code to create the missing classes.

Seems to work so far.

As long as we refresh the list of supported classes and have the CDN just as a fallback the build step is no longer such a big deal.

[onmax]

Using a custom pattern might help

safelist: [
    {
      pattern: /.*/,
    },
  ],

See Playground

[prodkt]

This is the one that handles it all, even when using multiple present and plugin imports.

[gdarko]

This change is really a no-sense. Makes custom tailwind builds unable to update to version 3. Not everyone needs JIT.