Feature request: Add a “responsive reset” behavior to allow overriding all breakpoint variants of a class group

[maximepvrt]

I’m using tailwind-merge inside a design system that autogenerates responsive classes (Nuxt UI in my case, but the problem applies to any UI library doing this).

When I try to override a class group (e.g. padding), I can override the base class, but not all responsive variants.

---

❌ Current behavior

twMerge("p-4 md:p-6 lg:p-8", "p-2")

Result:

p-2 md:p-6 lg:p-8

The base padding gets overridden (p-4 → p-2), but all responsive variants remain untouched.

---

🧩 Why this is a real issue in the ecosystem

When a design system generates responsive classes that I don’t directly control:

• I cannot predict all breakpoints
• I cannot ensure my override clears all variants
• If the design system adds a new breakpoint (e.g. xl:), my overrides suddenly break

Example:

twMerge("p-4 md:p-6 lg:p-8", "p-2 md:p-2 lg:p-2")
// ➜ p-2 md:p-2 lg:p-2

After a design system update adds a new breakpoint (e.g. xl:):

twMerge("p-4 md:p-6 lg:p-8 xl:p-12", "p-2 md:p-2 lg:p-2")
// ➜ p-2 md:p-2 lg:p-2 xl:p-12   ← unexpected leftover!

I now need to manually add xl:p-2, and the problem repeats every time new breakpoints are introduced.

---

🧨 Practical consequences

This becomes:

• verbose: you must manually override all breakpoints
• fragile: breakpoints added later break overrides
• anti-Tailwind: goes against the utility-first spirit where overrides should be simple and predictable
• hard for design systems: component overrides become unpredictable

---

🙏 Feature request

Add a way to reset all variants of a class group when one override is applied.

[dcastil]

Hey @maximepvrt, thanks for the long wait! 👋

I see the problem too, handling breakpoints with tailwind-merge isn't the best experience right now. I thought about solving this in the past but couldn't find a solution that worked UX-wise.

One of the unsolved problems to me is what to do in cases where conflicting base classes are used with other modifiers or where brekapoints are used together with other modifiers.

I.e. cases like these:

//                    ↓ Should any of these override breakpoints?
twMerge("p-4 md:p-6", "hover:p-2 p-2!")

//                          ↓ Should any of these override breakpoints?
twMerge("p-4 hover:lg:p-6", "p-2 dark:md:p-2")

I can imagine that what to do in these cases is dependent on the specific use case context and that there isn't a universal answer I could bake into tailwind-merge. But I would be happy to implement something to handle breakpoints better if there is one.

[maximepvrt]

@dcastil Thanks for your detailed explanation, makes a lot of sense! One simple idea could be to introduce an explicit “reset” class, e.g. twMerge("p-4 md:p-6 text-xl", "reset-p p-2") => text-xl p-2, that clears all previous padding classes (including responsive or state variants) before applying the new one. This keeps things predictable without guessing intent.

[dcastil]

Hmmmmm that is an interesting idea, I didn't consider doing this through explicit inputs.

This is probably too risky to add to tailwind-merge directly since non-tailwind classes are sometimes passed through it which could break with a feature like this. But what I could do is to add a way to hook into tailwind-merge so that people can build features like this into their tailwind-merge instance. I did something similar with experimentalParseClassName on the class level, but there is potential to build something similar on the level where all the classes are merged.

[dcastil]

Just added your use case here: #385 (comment)