Automatically pruning unused colors

[louisgv]

Hi @brattonross - Love the project!

I was wondering if it's possible to prune the CSS variable to just the subset that's being used automatically, without having to specify them by hand via the config.

One thought I have while reading the tw source code, is to utilize the matchUtility lifecycle for any color-related class (text, bg, border, etc...):

https://github.com/tailwindlabs/tailwindcss/blob/master/src/corePlugins.js#LL1603C18-L1603C18

Then, inside that match Utility, we construct an array of all the radix colors in use. (Actually, this array should be moved into a top-level variable so we can use it for both the theme extends and our plugin).

Then, after the matchUtilities call are done, invoke the addBase function with the constructed list of radix color found?

I suppose one draw-back of this approach is that the intelisense might foobar :d.... but I wonder how does tw do it?

[brattonross]

Pruning unused variables without having to manually specify colors would be great. I haven't really spent any time investigating how to do this, but your idea seems promising

[joaom00]

Hi @louisgv and @brattonross,

I played around a bit trying to get this to work and managed to prune unused colors and apply opacity modifiers to the colors, but the opacity only works in the light theme (or the default theme), see the generated CSS in the playground.

Do you have any idea how to make the opacity modifiers work when the prefers-color-scheme is dark?

Tailwind Play

[brattonross]

I gave this idea some thought during the recent v2 rewrite, so I now better understand the kind of trade-off we'd be making by implementing something like this. Tl;dr the downside of using matchUtilities is that we'd have to disable the default Tailwind color palette.

The main negative of continuing to generate all colors is that it increases the output CSS file size by around 125 kB (26 kB gzipped). Running Lighthouse on the demo site homepage gives a good performance score, but obviously warns that there is CSS that could be removed.

If we decided to add colors via matchUtilities, it would mean that this library must be updated if Tailwind ever decides to release new color utilities, whereas right now the colors just work with any color utility, even if it is brand new.

This isn't a massive downside, however; Tailwind is unlikely to release new color utilities often, and if this plugin is written well enough, I imagine updating would just mean something like adding an entry to some array of properties to generate. I think I'm okay with making that trade-off.

I've already started to hack around to see what a solution might look like, and found that in order to use matchUtilities, we'd need to disable the various Tailwind core plugins that handle color utilities. If these core plugins are left enabled, then Tailwind will complain that there are multiple matchers found.

The question then becomes are we okay with disabling the core color plugins (i.e. removing the ability to use Tailwind's default color palette)? Personally, I'm fine with this, but not sure how folks that use this plugin might feel about that.

Potentially there is also a nice upside to this implementation as well -- I could see it being possible to remove the need for the opacitySupport option, and have opacity just work.

I'm going to keep hacking around with this to see if I can get something working. Stay tuned :)