Automatically sort classes based on recommended class order, like prettier-plugin-tailwindcss plugin

[pingustar]

Hi,

I really like twMerge and I use it in combination with clsx with this helper function (credits go to @shadcn)

import { clsx, type ClassValue } from "clsx"
import { twMerge } from "tailwind-merge"
 
export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

What I am kind a missing is class sorting similar to the official prettier-plugin-tailwindcss plugin.

I assume that sorting the function arguments is kind a complicated and messy...

BUT would it be possible to sort the twMerge output?

Advantage would be that data compression would become significantly more efficient if there is more matching strings eg. classes in the same order.

Would love your thoughts on this!

Thanks for this great library!

[dcastil]

Hey @pingustar! 👋

thanks, I'm happy to hear you like the library!

I think sorting the output of the twMerge function within tailwind-merge isn't a good idea. Here are a couple reasons:

1. tailwind-merge only runs at runtime, so the sorting would only happen after the code was already sent to the browser. Therefore it wouldn't help with compression of the code sent over the wire to the browser. That's unless you're using SSR and running tailwind-merge on the server. But in that case the HTML is still a minority of the data sent and the classes are still unsorted in the sent JS code which hydrates the app.
2. Sorting in the same way as prettier-plugin-tailwindcss would require me to add a lot of code to tailwind-merge, making the library a lot larger than it is at the moment. That would mean sending more code to browsers and slowing down tailwind-merge which would go into the wrong direction for me.
3. It would require more resources to stay in sync with prettier-plugin-tailwindcss. Every time the plugin would change the classes order, I'd need to reimplement that in tailwind-merge. This would take a lot of time away from making tailwind-merge better on other fronts.

I think it's better to rely on prettier-plugin-tailwindcss to sort classes in your codebase. I'm also watching the discussion tailwindlabs/tailwindcss#7558 which would make the plugin work better with tailwind-merge.

Also, you can enable sorting of the twMerge output yourself without it being implemented within tailwind-merge. E.g. a simple alphabetical sorting of the classes could look like this:

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs)).split(' ').sort().join(' ')
}

[pingustar]

makes total sense, thanks!

[soutot]

@dcastil
Working with CSS the class ordering matters as class='bg-red-500 bg-blue-500' and class='bg-blue-500 bg-red-500' would have the same visual result as the stylesheet declaration decides what would be applied last.
I understand that tailwind sorting prettier plugin helps us to use the same class ordering as the tailwind's output stylesheet file, so we would not face this issue where a classname is the last in the string, but it's not the last in the stylesheet, because it gets reordered and we can see if any other classname is defined after.
I made some tests and, as you already confirmed, twMerge output is always the same as the input strings, save the case where we pass down a second conflicting argument. In this case, the conflicting classname as the second argument will be applied

Conflicting:

    const className = 'px-40 h-4'
    const override = 'px-20'
    twMerge(className, override) // output = 'h-4 px-20'

Sorting:

    const px = 'px-40'
    const bgRed = 'bg-red-500'
    twMerge(`${px} ${bgRed}`) // output = 'px-40 bg-red-500'
    <div className="px-40 bg-red-500" /> // on save, output = 'bg-red-500 px-40'

As we write more complex classes and deal with variables, would it be possible that we get an unexpected visual result due to the output not reflecting the correct sorting? Or is the conflict solving enough to keep us safe from this kind of error?

Also, you mentioned this in your answer tailwind-merge only runs at runtime, considering Next.js 13 docs that says:

Warning: CSS-in-JS libraries which require runtime JavaScript are not currently supported in Server Components

Is it safe to use twMerge in a production app using latest Next.js versions? Or should we always define use client for components that uses twMerge to compose the classNames?

Sorry for pinging you and sorry if I made any wrong assumption.

Thanks in advance

[dcastil]

Hey @soutot! 👋

As we write more complex classes and deal with variables, would it be possible that we get an unexpected visual result due to the output not reflecting the correct sorting? Or is the conflict solving enough to keep us safe from this kind of error?

tailwind-merge tries to preserve the input you pass it as much as possible, this is why tailwind-merge doesn't reorder the output classes, it only removes some classes from the output. Whether tailwind-merge reorders classes or not doesn't affect styling but it's still important to make the output more readable. E.g. it would be frustrating if you had to search through a long string of reordered Tailwind classes to understand whether a certain class is in the string or not.

Is it safe to use twMerge in a production app using latest Next.js versions? Or should we always define use client for components that uses twMerge to compose the classNames?

Yes, it's safe to use tailwind-merge in server components in Next.js. The reason why some CSS-in-JS libraries won't work is because they need access to browser APIs which don't exist on the server, but tailwind-merge doesn't use any of those. tailwind-merge can run anywhere where standard JS works. So tailwind-merge works in all modern browsers, Node.js, Bun, Deno, even Cloudflare Workers.

[soutot]

Thank you very much! Really appreciated it!

[spacecat]

I'm surprised this thread isn't longer.
The prettier plugin https://tailwindcss.com/blog/automatic-class-sorting-with-prettier makes absolut sense. My brain immediately tells me the classes should always be in the order from that blogpost.
It does make zero sense having some class attributes sorting one way (twMerge) and another, the tailwind and I would argue the proper way. In my world these two should always be in sync and consistent with one another.

I do see the performance issue and bundle size @dcastil described. And also the need to stay in sync with the plugin. Ultimately I would still like to see this feature in these sort of utilities and in this case tailwind-merge. As I said, I was 100% sure this would be included out of the box.

I also noted the date the plugin was released; Monday, January 24, 2022. It's rather new and tailwind-merge was created about 2 years ago.

Maybe there needs to be some sort of collaboration between the two projects, @dcastil ? Maybe the sort algorithm from the plugin is small with good performance. I don't know about others but I would be willing to trade-off a bit of performance and bytes for the sorting capability!

[dcastil]

Hey @pingustar! 👋

I'm actually a bit surprised that I didn't mention this in the discussion here, but prettier-plugin-tailwindcss and tailwind-merge have two very different purposes:

• prettier-plugin-tailwindcss is for sorting Tailwind classes as you're writing the code to make the strings more maintainable for developers.
• tailwind-merge is for merging or overriding Tailwind class strings together at runtime when using reusable components.

If you want the strings you pass into tailwind-merge to be sorted, you can use prettier-plugin-tailwindcss for it right now (I'm also using it myself), you don't need anything within tailwind-merge for that.

[spacecat]

Thanks for the reply, @dcastil. I'm also using both prettier-plugin-tailwindcss and will start using tailwind-merge now that I'm at that point in my code base (adding conditionals). I still think it's a bit funny though that not that many people are discussing this. Or maybe they are and I just haven't come across where :)

BTW, what would you recommend if I simply need to merge tailwind classes based on a condition? twJoin? I read it's faster and less code to ship to the user than clsx? How big is the difference between twJoin and twMerge? Because I'm thinking why not always use twMerge and forget about the rest.

[dcastil]

If you just want to concatenate strings with some conditions, I'd use twJoin (or clsx, they're very similar). Although you'll get the same result as with using twMerge, twJoin is significantly faster because it only concatenates the arguments together while twMerge does the same and additionally parses each class and categorizes it to find conflicts between classes which is much more expensive.

In practice the difference in a real app is only noticeable once you have hundreds of twMerge calls in a single page render. So for a small side project it probably doesn't matter. But if you're building something that should also work for users on low-end devices or is expected to grow to a large codebase, I'd try to only use twMerge when I really need it.

I also wrote some thoughts about this topic in #243 (comment) and #164 (comment).

[spacecat]

Perfect, thank you for the insight, it will help me decide what to use and when 😎