Provide all first party plugins for the bundled Tailwind CSS about tailwindcss-rails HOT 13 CLOSED

General problem is that we can't just include all the extensions. With everything included, I think the base TW CSS is something like 70mb. That clearly doesn't work. So need to find a way to configure things with what's needed.

from tailwindcss-rails.

If you want to use TW JIT, you'll have to do so through cssbundling-rails.

from tailwindcss-rails.

How big does the default bundle end up being? Just want to make sure it doesn't feel cumbersome in development.

from tailwindcss-rails.

Ok, so I've done some digging and think I came up with some answers.

I'm sure you already know how enabling variants work, but you have to specify which specific property you want to augment with the variant. The list of properties are pretty large.

For my testing, I only enabled a single variant on every property, bundled it with Webpacker, and looked at the bundle size (I assume the actual css file in the end is slightly smaller, but this was a quick way to crank through every variation and see the relative size impacts). I then subtracted the size of the base bundle from the plugin bundles to account for just their impact above the base styles. Here is what I found:

So including every variant for every plugin would come in at 9.97Mb. Even if that wasn't cumbersome, the order you include them has implications on how they're interpreted, and the default config of Tailwind provides their own ordering that they think is best.

Perhaps a less opinionated way to include all the variants in this gem would be to split up the css for each variant into separate files and include them in a main css file? It could look like something like:

*= require 'base'
*= require 'responsive'
*= require 'dark'
*= require 'focus'

Then the priority of variants are swappable by the end user. I'm not what the goal is as far as customizability when using the asset pipeline, but this would definitely provide some more flexibility

*edited to include value with no plugins (base) and adjusted the size of the variants with the base removed

from tailwindcss-rails.

Like being able to swap them around. And list them independently. Then we can go with a middle of the road default, but easily allow anyone to add additional plugins.

from tailwindcss-rails.

Throwing together a new project with Rails 6.1+, Hotwire and TailwindCSS. Surprised active state isn't included. Seems like a usual button styling. I'm not an expert on this configuration stuff but is it not possible to get this gem to install a tailwind.config.js and have some rake tasks...anything to allow more customization without webpacker?

from tailwindcss-rails.

The way I understand it, the goal of the asset pipeline version is to not need node installed. Tailwind compiles its css by using node, so using the tailwind.config.js wouldn't be possible without converting a good chunk of the Tailwind source into ruby.

All this gem currently provides is a pre-compiled version of tailwind with whatever options contributor had checked when they compiled it (the real need for this gem is the purging without node). It seems like the best path forward is what we discussed above: split the precompiled tailwind.css into smaller precompiled variant css files. That way everyone can just add in whichever variants they want to use for their project. Or they can compile their own precompiled tailwind plugins and include those as well.

from tailwindcss-rails.

I see. I'm all for the simplicity of setup, unless the dependencies between chunks gets complex.

Are we talking about naming exactly like the variants documentation?
*= require 'backgroundColor-active'

Even this without some 'tailwindcss/backgroundColor-active' namespacing is a little ambiguous, no?

Is it possible when doing rails tailwindcss:install that we copy a tailwind.css file to the stylesheets folder with all available requires and variants commented out? That would provide a definitive source of options.

Then maybe a rails tailwindcss:update task could diff these after updating the gem, adding anything new, putting a comment about something going away, and leaving uncommented variants intact?

from tailwindcss-rails.

Would it require that amount of granularity for variants though? It could just enable the variant for ALL properties to keep it simple (it all gets purged anyways). So it could generate a structure like:

/app/assets/stylesheets/tailwind.css
/app/assets/stylesheets/tailwind/_base.css
/app/assets/stylesheets/tailwind/variants/_active.css
/app/assets/stylesheets/tailwind/variants/_focus.css
/app/assets/stylesheets/tailwind/variants/_disable.css
/app/assets/stylesheets/tailwind/plugins/_forms.css
...

Then the tailwind.css could look like

*= require 'tailwind/base'
*= require 'tailwind/variants/active'
*= require 'tailwind/variants/focus'
*= require 'tailwind/plugins/forms'
...

It would just default to having the most desired files included. Granted, if a per-property granularity was desired, maybe it could look like:

/app/assets/stylesheets/tailwind.css
/app/assets/stylesheets/tailwind/_base.css
/app/assets/stylesheets/tailwind/variants/_active.css
/app/assets/stylesheets/tailwind/variants/active/_background_color.css
/app/assets/stylesheets/tailwind/variants/active/_height.css
....

Then, in this instance, variants/_active.css could just require all the files under the variants/active/ directory, but then you'd have the ability to be extremely specific in the main css file

*= require 'tailwind/base'
*= require 'tailwind/variants/active/background_color'
*= require 'tailwind/variants/focus'
*= require 'tailwind/plugins/forms'

This would just lead to a lot of files though. If I counted right, there are ~107 properties and ~18 variants, so this would generate 1926 files. The only benefit I could think of is it would let you keep the file smaller in the dev environment. Which maybe that is worth it for devs who need to use combinations of every variant. I could easily be missing other benefits though

from tailwindcss-rails.

Some news on this? I'm playing around with rails 7 alpha and tailwindcss-rails, and right now I need to use the first-child, and probably I'll end up using most of the things pointed here. What can we do to help on this?

from tailwindcss-rails.

There's actually a bigger issue, though, which is that Tailwind has been adding a series of new features that depend on the JIT compiler because otherwise the bundle would be too big (see https://blog.tailwindcss.com/tailwindcss-2-2), and unless I'm missing something (always a possibility), there's no way to use those via this gem, we'd need some way to integrate the JIT compiler into the asset pipeline, right?

from tailwindcss-rails.

I just bumped into this one as well using tailwind and Rails 7.

I'm a big fan of this gem because it's great not to require node.js setup but at the same time at least 4-6 of these variants are so common that I feel like they should be included in the default or we should have a way to add them easily using a require as mentioned above.

The ones I feel should be included by default are the following:

• first-child
• last-child
• active
• checked
• maybe odd and even ?

from tailwindcss-rails.

I think the option here is to wait for compatibility with TW 3 that uses JIT.

from tailwindcss-rails.