tailwind v4 and tailwind merge

[flozero]

I am really looking forward to Tailwind v4. I plan to start experimenting with it soon.

I'm here today to ask if there's anything that can be done to facilitate the transition to third-party modules like tailwind-merge (dcastil/tailwind-merge#468).

This library is super useful for component libraries and overrides.

To give you more context:

• I have built a library called Tailwind Buddy (https://github.com/busbud/tailwind-buddy), which is similar to Class Variant Authority and Tailwind Variant but faster. It's designed to build component functions that also handle responsiveness.
• In cases of compound conditions or even className overrides from outside of the component, we don't want to keep HTML classes that we don't use. I know Tailwind, at least in v3, was smart enough to put the classes from left to right in the correct order as there are no specificities.
• Another question: Wouldn't it be super useful to integrate a library like tailwind-merge directly into the Tailwind library or facilitate its use, as it's really useful for component library maintainers?

Thank you for your time and your work!

[sebastiancarlos]

Wouldn't it be super useful to integrate a library like tailwind-merge directly into the Tailwind library or facilitate its use, as it's really useful for component library maintainers?

I'd love to hear the official stance on this. Even a general or vague answer would help give some insight into how both Tailwind and tailwind-merge might evolve.

[joshistoast]

Having a native helper function for class merging would be huge

[gustavopch]

Wouldn't it be super useful to integrate a library like tailwind-merge directly into the Tailwind library or facilitate its use, as it's really useful for component library maintainers?

Now that there's a Vite plugin, I believe they could automatically insert a merge function in all places where classes are specified, e.g.:

• className={...} -> className={twMerge(...)}
• const className = ... -> const className = twMerge(...)

And, with awareness of what classes exactly are used in the codebase, this twMerge() function could perhaps be optimized/pruned to weight as little as possible to reduce the impact in bundle size.

EDIT: basically the same idea as described here: dcastil/tailwind-merge#413 (comment)

[rsimp]

I think a lot of the problems tailwind merge solves can also be solved by having styling split between the component and utility layers. However its very common to use tailwind for at least property modifiers, but also for base component styling by tools like shadcn.

I wonder if tailwind could just have a configurable prefix to use a class on the component layer. So m-0 would be on the utility layer as usual, but cmp-m-0 would be on the component layer. Internal component code would use the prefix and passed in classes would just use the normal class names.

You could also have this plug into a variant, but the idea only works if you duplicate the classes for the differing specificity.

[gustavopch]

If this can really solve the problem and ends up being the chosen solution, I'd vote for ?m-0 to resemble the nullish coalescing operator, like "this is the class that's applied as fallback".

[rsimp]

I'm not sure if you may need another layer for base component styling (or alternatively a component modifier layer), and it doesn't help anyone arbitrarily appending to a class list to overwrite previous styles. But for most cases this will solve many of the same issues without having to use a utility.

I think providing a tool like tailwind merge natively is still a great idea that would help a lot with adoption of v4.

[gustavopch]

FWIW, Adam hinted at something like this last year: https://x.com/adamwathan/status/1818041514863608141

[rsimp]

Yeah something exactly like that. Just something to mark it slightly lower specificity than the standard utilities.

Then you can just use the default utilities for all internal component styling, or use the @components for base styling, the default utilities for variants/property modifiers, and any passed in utilities will still get precedence.

[rsimp]

It's also pretty simple to determine when to use. Just use default on everything that you merge with classNames. You could even create a simple utility to do it for you.

[maiieul]

Qwik UI maintainer here 👋 I am exploring an idea that might seem controversial but I find it more and more appealing. Tailwind 4 uses native css @layer by default, so we can leverage this css feature to enable class names overrides on our components. There are quite a few performance and DX benefits to this approach, the only downside is that we need to define a separate css file containing the overridable classes in the @layer.

I wrote an RFC detailing how it works and what the benefits are: qwikifiers/qwik-ui#1111.

Edit: here's the simplified concept if you don't have time to go through the RFC: https://play.tailwindcss.com/sORZZZiz1I