make twMerge take into account different then the orignal class order definition

[tkozuch]

twMerge("p-2", "md:p-4") returns "md:p-4 p-2"

it's a result one would expect, because when Tailwind generates CSS, media query classes are after normal classes, and for that reason, p-2 shouldn't overwrite md:p-4

is there any way (can be a hacky one) to tell twMerge that a particular class is defined later or sooner in Tailwind? or tell it that a particular class has higher specificity?

example of what I would want:

considering that "p-2" is for some reason defined after "md:p-4" in the CSS, I would want:

twMerge("p-2", "md:p-4") to return "p-2" ("p-2" overwrites, "md:p-4")

Disclaimer:

I know it's not a primary purpose of twMerge to handle such cases. I suspect it is strongly (and probably exclusively, as the name suggest) directed to work with Tailwind originally generated CSS.

But I'll also accept any "hacky" answers - for example:

In twMerge "!p-2" will overwrite "md:p-4" because of the "important" modifier. So knowing that a particular class is defined after a particular other, I could just append "!" to the one of which I know is defined later in the CSS.

The problem with this would be however if I had more classes that I needed to merge, as I can't add multiple "!" modifiers.

What I ultimately would want:

/* Css order
  .sm:class-1
  .md:class-1
  .class-1
*/
const tailwindClasses = [ "class-1", "md:class-1", "sm:class-1] // for simplicity, let's consider all the classes are related to the same property
twMerge(...) // don't want to suggest in which order classes are put here, as that could also be potentially used to solve the problem

// twMerge returns -> "class-1"  (because it was defined after the `sm:` and `md:` modifiers classes)

but

/* Css order
  .sm:class-1
  .class-1
  .md:class-1
*/
const tailwindClasses = [ "class-1", "md:class-1", "sm:class-1]
twMerge(...)

// twMerge returns -> "class-1 md:class-2"  (because `class-1` is now defined after `sm:` modifier class, but also `md:` modifier class is defined after it, so both `class-1` and `md:class-2` should stay, as you would with the CSS)

Notes:

1. I know the order of the CSS classes definition when using twMerge.
2. I can accept any answers that would suggest modyfing the class names to reach the desired outcome, in example: in Tailwind, adding **[:where(&)]** modifier to class can be used to reduce class specificity (https://play.tailwindcss.com/8sLgiUISGB), but as this gives desired outcome in terms of output styling applied, twMerge seems to not take it into account when reducing the number of classes which in turns could result in bloated HTML file - for this reason I would prefere to handle this on the twMerge, not Tailwind's level, as described in examples above. But if the solution includes modification of the class before using twMerge, I can also use it, as later in the result I could just potentially "subtract" that modification.

[dcastil]

Hey @tkozuch! 👋

Yes, there is a way to customize the tailwind-merge internals to an extent. When configuring tailwind-merge, there is a property experimentalParseClassName that allows you to hook into the internals.

It is only documented via TypeScript and JSDoc right now here:

• Function property: https://github.com/dcastil/tailwind-merge/blob/v3.3.0/src/lib/types.ts#L23-L29
• Function parameters: https://github.com/dcastil/tailwind-merge/blob/v3.3.0/src/lib/types.ts#L32-L40
• Function return value: https://github.com/dcastil/tailwind-merge/blob/v3.3.0/src/lib/types.ts#L42-L83

You can get the behavior you want by removing the responsive modifiers from the parsed class name, then tailwind-merge will treat all classes as if these modifiers weren't present. The parsed class name data is only used internally and the original class name string will be preserved in the output, so it's safe to modify that data.

import { extendTailwindMerge } from 'tailwind-merge'

const responsiveModifiers = ['sm', 'md', 'lg', 'xl', '2xl']

const twMerge = extendTailwindMerge({
  experimentalParseClassName({ className, parseClassName }) {
    const parsed = parseClassName(className)
    parsed.modifiers = parsed.modifiers.filter((mod) => !responsiveModifiers.includes(mod))
    return parsed
  },
  // rest of config
})

Keep in mind that the API can change with any minor release since it's experimental. But I don't have any plans to change the API right now. It's more likely that I'll add it as non-experimental sooner or later.

[tkozuch]

Hi. Thank you for this detailed answer. It seems though as I won't be able to achieve all the necessary conditions I need with this.

If I just get rid of the modifiers, then the case when "no-media-query" rule is defined after similar "media-query-rule" is in fact solved, but I also need to fulfill the more common scenarios where the "media-query-rule" is defined after "no-media-query-rule" and I'm looking to fulfill both cases with the same TwMerge.

From what I see if we get rid of the modifiers, in the latter scenario (media query after no-media-query) I will just get the media-query class in this scenario, while in reality, I should get both:

md:p-0
p-2

(p-2 defined after md:p-0) -> twMerge should return only p-2

p-2
md:p-0

(md:p-0 defined after p-2) -> twMerge should return both md:p-0 and p-2 - this is not satisfied here

or am I missing something?

[dcastil]

Oh you're right. Hmmmm that's a tricky case. I'm also wondering how the different modifiers relate to each other. E.g. if you have p-0 lg:p-0 md:p-0 xl:p-0, then the output should probably be p-0 md:p-0 xl:p-0, so breakpoints only override other breakpoints that are higher than themselves but not lower.

I think there is no sensible way to get tailwind-merge to do that. In that case you can fork tailwind-merge and look into modifying https://github.com/dcastil/tailwind-merge/blob/v3.3.1/src/lib/merge-classlist.ts to support your use case.