Is it possible to generate config based on the output css file?

[illiaChaban]

I wonder if it makes sense to generate tw-merge config from the output css file. This way it wouldn't need custom code for tw plugins and would only use styles that are used on the codebase as opposed to loading everything. It would also support any custom tw extensions out of the box.
The idea is basically this: add a vite plugin (that's what i use at the moment) to use postcss to parse output css file (should work for development and production), generate a map of conflicting classes and generate a file that exports twMerge function.
This function can then be used in development and the resulted bundle is as lean and mean as possible

[illiaChaban]

i actually managed to create an almost working prototype with a custom postcss plugin and was able to generate a file
I wonder if I can do smth similar to this:

import { getDefaultConfig } from 'tw-merge'

const myCustomPostcssPlugin = () => {
  // parse css rules, get used css classes
  // generate new config, filter default config by used classes + add custom classes from tailwind config
  const newConfig = doSomething(getDefaultConfig()) 

      const dirPath = __dirname + '/test/_generated'
      tryCreateDir(dirPath)
      fs.writeFileSync(dirPath + '/tw-config.ts', `
        import { createTailwindMerge } from 'tw-merge'
        
        export const twMerge = createTailwindMerge(${() => newConfig})
     `);
 
}

[dcastil]

This is an interesting idea, indeed! I also thought about something like this a few times but never got around to build it due to lack of time. There is also an open discussion on the Tailwind repo to add support for something like that: tailwindlabs/tailwindcss#10348

I think it would be a rather large undertaking to read a CSS file directly, but it's possible. Some reasons that make this difficult:

• We'd need to parse the entire CSS selectors and nested selectors to understand which classes are in conflict with each other. For classes like ring or hover:ring that might be somewhat easy, but once modifiers get stacked like dark:md:hover:ring or complex arbitrary variants are used, the generated CSS can get quite complicated to parse.
• The CSS file can include non-Taiwind-generated CSS with arbitrarily complex CSS selectors which we can't easily separate from Tailwind classes.
• tailwind-merge allows refinements, i.e. p-4 pr-5 won't be changed but pr-5 p-4 will. But both of those classes set different CSS properties. That means that the generator would need to know that the padding-right property is also included in padding but not the other way around. There are many such shorthand properties and tailwind-merge would need a large map of those to figure it out correctly.

The gist is that I would find a generator like that really valuable, but it would be too much for me to handle next to maintaining the current codebase, my day job and other priorities. If you're up for the challenge, feel free to build it yourself! I'd be happy to work on the necessary API within tailwind-merge for that.

---

Related: #185

[illiaChaban]

for point 1 my idea was to separate the "main" class and modifiers, i.e dark:md:hover:ring -> ring + [dark, md, hover], determine what properties are affected by the "main" class (ring -> "box-shadow") and then the tw-merge could only replace classes that have the same modifiers & affect the same properties.

for point 2, that's true. For initial implementation I could probably ignore those classes completely, since they don't conform to "utility-first" approach

for point 3, I have thought about it and Idk whether it's worth the effort to support it, at least for POC. Since the tw stylesheet is deterministic and the classes always have the same order, it might be ok to leave p-4 pr-5 and pr-5 p-4 as is. This feature could probably be added as an improvement after a working prototype. All i would have to do is to map those shorthand properties to an array of properties.

I would appreciate your guidance in this. Maybe you could point me to some tests in tw-merge package that I could reuse?

[dcastil]

Sure! All the tests for tailwind-merge are here: https://github.com/dcastil/tailwind-merge/tree/v2.3.0/tests. Each file is testing a specific topic that you can check out.

[illiaChaban]

i thought about what you said regarding p-4 pr-5 and pr-5 p-4 and I agree with you. I think, however, i'll take a slightly different approach and try to accomplish the same thing, but instead of relying on style specificity defined in code (i.e. pr-5 is more specific than p-4, thus wins and p-4 doesn't need to be removed), i can rely on stylesheet rules order (p-4 is defined before pr-5 based on TW configuration, thus pr-5 wins). So in this case I will only remove classes if latest added class has lower order (would lose by default). It should accomplish the same thing (p-4 pr-5 -> p-4 pr-5, pr-5 p-4 -> p-4). However, there's an edge case where based on this approachpx-2 px-3 -> px-2 px-3 will stay the same. It's probably ugly, but should still result in expected result from the UI point of view
To sum up, instead of relying on the hardcoded style specificity / rules, I'll rely on TW default class order. Since by default their classes are defined from less specific to more specific, i think it should work

Do you see any pitfalls with this approach?

[illiaChaban]

i think eventually what i want to do is to create a minimal "tailwind-styled-components" like package that supports tw-merge out of the box + simpler api where tw can be used as styled and to organize code & merge classNames (when there's many classes applied, so you can organize the classes on multiple lines)

API example:

import {tw} from 'tw-styled'

const MyStyledComponent = tw('div')`
  flex text-3xl
 ${p => p.showBorder && 'border'}
`
const Composed = tw(MyStyledComponent)` ... `

const AnotherComponent = () => ( 
 <div class={tw`
    flex flex-column
    ...
 `>
     <MyStyledComponent 
        class={tw`
           block
           ${makeWhite ? 'text-white' : 'text-black'} 
           ...
        `} 
     />
 </div>
)

I already have tw part working for SolidJS at least, but merge functionality is what's missing
I wonder if you have any thoughts on that ^^

[dcastil]

Looks cool! You could also just use tailwind-merge for the merging functionality in the beginning and then replace it with your own logic in an iteration. Then you can get it out the door faster.

[illiaChaban]

i could, but solid-styled-components is very close to 1kb in size and I feel like my solution doesn't offer much benefit over it if it requires a lot more memory upfront. After all, the main benefit of TW is style reuse and tiny bundle

[illiaChaban]

Hey @dcastil,

i have created this plugin. It seems to work well & passes all tests from this repo (except for ring VS shadow test, which i probably won't support because it's a very special case and there's a workaround). I also haven't tested custom prefix and custom separators, but I don't foresee any issues, i just didn't have time to write those tests for custom tailwind configs.
Anyway, it passes all tests and is fully generated based on the incoming css. The code is still very messy and I plan to do some performance optimizations. This being said it supports custom plugins out of the box and seems to work well!
I'm planning to publish this soon. Wanted to get your feedback and thank you for the help.

Implementation TLDR. the way it works is I have a postcss plugin that parses styles after tailwind plugin and then generates a minimized config that has this structure:

Non-minimized:
{[className]: {[property]: {order: number, value: string, isImportant: boolean}} 
Example:  { "p-2": { "padding-top": {order: 1, value: '4px', isImportant: false} , "padding-right": ...}}

Then i minimize this config into
{[className]: {[minProperty]: {o, v, i}}
Since i don't really care about the actual values of "property" and "value" i can safely replace it with any value (number or a character) as long as there's a 1 to 1 mapping
I only use those to see if incoming styles update anything, but don't actually care about values

so previous class "{ "p-2": { "padding-top": {order: 1, value: '4px', isImportant: false} , "padding-right": ...}}"
becomes {"p-2": {"a", {o: 1, v: 0, i: 0}, "b": {...} ..}}

I think this is a pretty small & efficient way to store this metadata that i then use it to create "twMerge" that does all the merging logic based on this config

Given that there's 1:1 mapping between tailwind generated css, there's an out of the box support for plugins

[dcastil]

Yeah nice, that is quite a lot smaller than the 6 kB that are produced by the full config. I'll try to test the config size on a production codebase in the coming days. Hope I'll find time for it. 😬

I could probably shave off some of it if i restructure my data, because "value" (v) and "order" (o) seem to repeat a lot, in most cases unnecessarily

To compress a bit further you could use an array instead where index 0 is the value, index 1 is the order and optional index 2 is the important value.

[dcastil]

A big opportunity to reduce the config size could be to summarize similar keys. E.g. there is no need to store the full config for both keys hover:group-empty:p-2 and hover:group-empty:p-3, instead you could store something like hover:group-empty:p-<number> and apply it to any class with a number in the same place.

[illiaChaban]

one big benefit is that we don't need to write custom plugins anymore. It should handle everything out of the box since it's css file driven.
You're right about compressing classNames like hover:group-empty:p-<number>, however this requires embedding tailwind specific class structure logic into merge logic, since we'd have to make assumptions based of class name and what props it updates. I think the way this plugin is written now is pretty much generic and css library agnostic (with small updates). I can probably use it on any css file. It should work with unoCss out of the box as well

Also hover:group-empty:p-<number> approach would probably not work very well with storing "order" since it's class specific

[illiaChaban]

i'll test the array approach, see if it makes any difference

[illiaChaban]

after some experimenting, I was able to compress the config even more from 2.53 kB to 2.16 kB (gzip), but I couldn't figure out how to compress classNames. After some thinking I realized that gzipping is supposed to be very good at compressing repeating strings, so there's probably no point in even trying. In one of my experiments I was able to lower non-gzipped bundle size by doing some magic over classNames, but gzipped size was actually larger. So because of this my guess is that writing code to support hover:group-empty:p-<number> case to try to reduce bundle size is not worth it, because the code needed to support it will likely outweigh the benefits in the end.

Here's the final compressed config example

{
  "inset-1": ["a,b,c,d", 0, 1],
  "!-inset-x-px": ["d,b", 1, 2, 1],
  "inset-x-1": ["d,b", 0, 3],
  "inset-y-1": ["a,c", 0, 4],
  "!right-2": ["b", 2, 5, 1],
  "-right-1": ["b", 3, 6],
  "-top-12": ["a", 4, 7],
  "-top-[50px]": ["a", 5, 8],
  "-top-[69px]": ["a", 6, 9],
  "left-1": ["d", 0, 10],
  "right-1": ["b", 0, 11],
  "top-12": ["a", 7, 12],
  "z-20": ["e", 8, 13],
  "z-[99]": ["e", 9, 14],
  "-m-2": ["f,g,h,i", 10, 15],
  "-m-5": ["f,g,h,i", 11, 16],
  "m-[10dvh]": ["f,g,h,i", 12, 17],
  "m-[10px]": ["f,g,h,i", 13, 18],
  "m-[10rem]": ["f,g,h,i", 14, 19],
  "m-[11svmin]": ["f,g,h,i", 15, 20],
  "m-[12in]": ["f,g,h,i", 16, 21],
  "m-[13lvi]": ["f,g,h,i", 17, 22],
  "m-[14vb]": ["f,g,h,i", 18, 23],
  "m-[15vmax]": ["f,g,h,i", 19, 24],
  "m-[16mm]": ["f,g,h,i", 20, 25],
  "m-[17%]": ["f,g,h,i", 21, 26],
  "m-[18em]": ["f,g,h,i", 22, 27],
  "m-[19px]": ["f,g,h,i", 23, 28],
  "m-[2px]": ["f,g,h,i", 24, 29],
  "m-[calc(100%-var(--arbitrary))]": ["f,g,h,i", 25, 30],
  "m-[length:var(--mystery-var)]": ["f,g,h,i", 26, 31],
  "m-auto": ["f,g,h,i", 27, 32],
  "my-[2px]": ["f,h", 24, 33],
  "mt-2": ["f", 2, 34],
  "mt-[calc(theme(fontSize.4xl)/1.125)]": ["f", 28, 35],
  "line-clamp-1": ["j", 29, 36, 0, "k", 30, 36, 0, "l", 31, 36, 0, "m", 32, 36],
  "block": ["k", 33, 37],
  "inline": ["k", 34, 38],
  "flex": ["k", 35, 39],
  "h-10": ["n", 36, 40],
  "h-[10px]": ["n", 13, 41],
  "h-[11cqw]": ["n", 37, 42],
  "h-[12cqh]": ["n", 38, 43],
  "h-[13cqi]": ["n", 39, 44],
  "h-[14cqb]": ["n", 40, 45],
  "h-[15cqmin]": ["n", 41, 46],
  "h-[16cqmax]": ["n", 42, 47],
  "h-min": ["n", 43, 48],
  "min-h-[0.5px]": ["o", 44, 49],
  "min-h-[0]": ["o", 45, 50],
  "w-1/2": ["p", 46, 51],
  "w-full": ["p", 47, 52],
  "grow": ["q", 32, 53],
  "grow-[2]": ["q", 48, 54],
  "scale-75": ["r,s", 49, 55, 0, "t", 50, 55],
  "scale-[1.7]": ["r,s", 51, 56, 0, "t", 50, 56],
  "cursor-[grab]": ["u", 52, 57],
  "cursor-pointer": ["u", 53, 58],
  "touch-auto": ["v", 27, 59],
  "touch-none": ["v", 54, 60],
  "touch-pan-x": ["w", 55, 61, 0, "v", 56, 61],
  "touch-pan-right": ["w", 57, 62, 0, "v", 56, 62],
  "touch-pan-y": ["x", 58, 63, 0, "v", 56, 63],
  "touch-pinch-zoom": ["y", 59, 64, 0, "v", 56, 64],
  "touch-manipulation": ["v", 60, 65],
  "grid-rows-2": ["z", 61, 66],
  "grid-rows-3": ["z", 62, 67],
  "grid-rows-[1fr_500px_2fr]": ["z", 63, 68],
  "grid-rows-[1fr_auto]": ["z", 64, 69],
  "overflow-auto": ["j", 27, 70],
  "border-b": ["A", 65, 71],
  "border-t": ["B", 65, 72],
  "border-[#243c5a]": ["C", 32, 73, 0, "D", 66, 73],
  "border-slate-800": ["C", 32, 74, 0, "D", 67, 74],
  "border-white": ["C", 32, 75, 0, "D", 68, 75],
  "border-white/10": ["D", 69, 76],
  "bg-custom-pink": ["E", 32, 77, 0, "F", 70, 77],
  "bg-gray-50": ["E", 32, 78, 0, "F", 71, 78],
  "stroke-[hsl(350_80%_0%)]": ["G", 72, 79],
  "stroke-black": ["G", 73, 80],
  "stroke-1": ["H", 32, 81],
  "stroke-2": ["H", 48, 82],
  "stroke-[10px]": ["H", 13, 83],
  "stroke-[3]": ["H", 74, 84],
  "p-2": ["I,J,K,L", 2, 85],
  "p-[calc(theme(fontSize.4xl)/1.125)_10px]": ["I,J,K,L", 75, 86],
  "px-4": ["L,J", 76, 87],
  "pb-6": ["K", 77, 88],
  "text-[0.5px]": ["M", 44, 89],
  "text-lg/7": ["M", 78, 90, 0, "N", 79, 90],
  "text-lg/8": ["M", 78, 91, 0, "N", 80, 91],
  "text-lg/none": ["M", 78, 92, 0, "N", 32, 92],
  "!font-bold": ["O", 81, 93, 1],
  "!font-medium": ["O", 82, 94, 1],
  "font-thin": ["O", 83, 95],
  "leading-9": ["N", 84, 96],
  "text-[--my-0]": ["P", 85, 97],
  "text-[color:0]": ["P", 45, 98],
  "text-black": ["Q", 32, 99, 0, "P", 86, 99],
  "underline": ["R", 87, 100],
  "line-through": ["R", 88, 101],
  "no-underline": ["R", 54, 102],
  "opacity-10": ["S", 89, 103],
  "opacity-[0.025]": ["S", 90, 104],
  "mix-blend-normal": ["T", 91, 105],
  "mix-blend-multiply": ["T", 92, 106],
  "outline-1": ["U", 65, 107],
  "outline-black": ["V", 73, 108],
  "brightness-90": ["W", 93, 109, 0, "X", 94, 109],
  "brightness-[1.75]": ["W", 95, 110, 0, "X", 94, 110],
  "grayscale-0": ["Y", 96, 111, 0, "X", 94, 111],
  "grayscale-[50%]": ["Y", 97, 112, 0, "X", 94, 112],
  "content-['hello']": ["Z", 98, 113, 0, "0", 99, 113],
  "content-[attr(data-content)]": ["Z", 100, 114, 0, "0", 99, 114],
  "no-scrollbar": ["1,2", 54, 115, 0, "3", 54, 116],
  "all-unset": ["4", 101, 117],
  "all-inherit": ["4", 102, 118],
  "[--my-var:2rem]": ["5", 80, 119],
  "[--my-var:4px]": ["5", 103, 120],
  "![display:block]": ["k", 33, 121, 1],
  "[display:inherit]": ["k", 102, 122],
  "![display:inline-block]": ["k", 104, 123, 1],
  "[display:inline]": ["k", 34, 124],
  "[paint-order:markers]": ["6", 105, 125],
  "[paint-order:normal]": ["6", 91, 126],
  "[src:local(serif)]": ["7", 106, 127],
  "[src:url(https://hi.com)]": ["7", 107, 128],
  "after:absolute": ["8", 99, 129, 0, "9", 108, 129],
  "after:left-0": ["8", 99, 130, 0, "+", 109, 130],
  "read-only:p-2": ["=,_,-,)", 2, 131],
  "read-only:p-3": ["=,_,-,)", 110, 132],
  "empty:p-2": ["(,*,&,^", 2, 133],
  "empty:p-3": ["(,*,&,^", 110, 134],
  "focus-within:block": ["%", 33, 135],
  "focus-within:inline": ["%", 34, 136],
  "hover:left-1": ["$", 0, 137],
  "hover:m-[2px]": ["#,@,!,~", 24, 138],
  "hover:m-[length:var(--c)]": ["#,@,!,~", 111, 139],
  "hover:block": [".", 33, 140],
  "hover:inline": [".", 34, 141],
  "hover:bg-custom-pink": ["<", 32, 142, 0, ">", 70, 142],
  "hover:bg-gray-50": ["<", 32, 143, 0, ">", 71, 143],
  "hover:[paint-order:markers]": ["/", 105, 144],
  "hover:[paint-order:normal]": ["/", 91, 145],
  "hover:empty:p-2": ["?,:,;,[", 2, 146],
  "hover:empty:p-3": ["?,:,;,[", 110, 147],
  "focus:!block": ["]", 33, 148, 1],
  "focus:!inline": ["]", 34, 149, 1],
  "focus:inline": ["]", 34, 150],
  "focus:hover:inset-x-1": ["{,}", 0, 151],
  "hover:focus:inset-x-1": ["{,}", 0, 152],
  "hover:focus:-right-1": ["}", 3, 153],
  "focus:hover:m-[length:var(--c)]": ["|,aa,ab,ac", 111, 154],
  "hover:focus:m-[2px]": ["|,aa,ab,ac", 24, 155],
  "hover:focus:block": ["ad", 33, 156],
  "focus:hover:inline": ["ad", 34, 157],
  "hover:focus:inline": ["ad", 34, 158],
  "hover:focus:[paint-order:markers]": ["ae", 105, 159],
  "focus:hover:[paint-order:normal]": ["ae", 91, 160],
  "group-read-only:p-2": ["af,ag,ah,ai", 2, 161],
  "group-read-only:p-3": ["af,ag,ah,ai", 110, 162],
  "group-empty:p-2": ["aj,ak,al,am", 2, 163],
  "group-empty:p-3": ["aj,ak,al,am", 110, 164],
  "hover:group-empty:p-2": ["an,ao,ap,aq", 2, 165],
  "hover:group-empty:p-3": ["an,ao,ap,aq", 110, 166],
  "peer-empty:p-2": ["ar,as,at,au", 2, 167],
  "peer-empty:p-3": ["ar,as,at,au", 110, 168],
  "lg:[--my-var:4px]": ["av", 103, 169]
}

This object is then converted to a more easy to work with object and it's used to figure out class conflicts.