Tailwindcss: [Feature Proposal]: Add 'extend' for `variants` in config.js like as did for `theme`

[Quineone]

current

theme: {
   extend: {}
}

expected

variants: {
   extend: {}
}

[hacknug]

The issue here is that order of those variants is important and extending the default values would probably cause issues with some of them.

[adamwathan]

Since the order of variants is so important, I'm not planning to add support for this any time soon as there's no good way to extend the defaults and also control the order.

[sebastiandedeyne]

Would you consider supporting functions in variants, similar to theme?

This way I wouldn't need to remember the default values whenever I want to modify the variants.

variants: {
    borderWidth: variants => [...variants, 'first', 'last'],
}

[zaydek]

I would also like to see this but I totally understand the concern with order. I was quite surprised to learn that order a variant is listed can _break_ those classes, but this is a limitation with CSS, not with Tailwind itself.

That being said, if anyone stumbles on this issue in the future, I think what you’re looking for, at least what I needed, was this: https://tailwindcss.com/docs/configuring-variants/#default-variants-reference.

[Landish]

Hey @adamwathan , what do you think about @sebastiandedeyne's solution above?

I was going to create feature proposal about this topic with the same exact solution, but then i found this issue and your concerns.

If it's possible to have the function version as well, without messing css variants order, that would be absolutely amazing.

[adamwathan]

Yeah I would be open to the function implementation definitely 👍🏻

[adamwathan]

Random idea so I don’t forget, we currently pass some utility functions along as the second argument when you use the function syntax. We could create some useful utilities for this situation that let you insert variants at a specific spot in the list, like (on phone so forgive formatting)...

backgroundColor: (variants, { before }) => before(‘hover’, [‘disabled’])

It could be a partially applied function that knows about the current key as suggested above, or we could keep it simple and require you pass the variants in as the first arg. Could do “after” as well.

[adamwathan]

I’ll probably build this tomorrow if someone doesn’t PR it sooner, kinda excited 😅

[Landish]

The main idea behind this feature is that to write less code (variants) and not to memorize the order or go to the docs every time we need to add new variant.

So, for me personally this code is overkill for simply adding a group-hover variant to selectors:

backgroundColor: (variants, { before }) => before(‘hover’, [‘disabled’])

rather than this:

backgroundColor: variants => [...variants, 'first', 'last']

So, I would stick to simpler solution.

But, if the before or after args will not be required, then I guess, I can live with that. 😄

On the other hand, since Tailwind comes with purge option, and i'm pretty sure that everyone is purging in production, why not add all variants to all selectors? 😄 How much more MB it will add to CSS file in development mode? 10? 100? 😄

[Landish]

I just realized that at this moment we can achieve same result with the following code:

const { variants } = require('tailwindcss/defaultConfig');
// ...
variants: {
   textColor: [...variants.textColor, 'group-hover']
},