Reduce bundle size during build process?

[whytspace]

First I would like to say a huge thanks to the maintainers of this package. I stumbled upon the class merging problem the very first time I used tailwind in a React project and was about to write my own solution when I found this one 👍

So far I have used clsx (and className before) and always liked their low impact on performacne and bundle size. Whenever I start using a new package I do a quick test on how much it adds to the production bundle and I must say I was a unpleasantly surprised when I saw the results for this package.

Here a quick comparison:

(I am using a newly created Solidjs App for size comparison)

Using string concatination: "p-2 " + props.className

Using clsx: clsx("p-2", props.className)

Using tailwind-merge: twMerge("p-2", props.className)

---

Taking a closer look at the bundle, most of the file size comes from the default configuration object. It includes a lot of classes for maximum compatibility, but most of them are not used in my application.

I was wondering if there was a way to only bundle the necessary parts of the configuration. Similar to what the just-in-time compiler does for tailwind itself.

What do you think about that? Is that a good idea?
Is it even worth the effort? (As the bundle size of the app grows tailwind-merge's configuration gets smaller compared to the total size)

[dcastil]

Hey @whytspace! 👋

I like the idea of leveraging the Tailwind CSS compiler! I think I'll ask the Tailwind maintainers whether they could provide an API for it. Thanks for the suggestion!

So far tailwind-merge is just a simple static library, so I need to include support for all possible Tailwind classes in the default config. It is also not possible for Tailwind plugins to see which Tailwind classes got built, so there currently isn't an obvious way for me to dynamically reduce the bundle size unfortunately.

If bundle size is really important to you, there are two possible solutions in the short term:

1. Don't use tailwind-merge

If bundle size is everything and you don't have crazy merging needs, you might get away with using the Tailwind important modifier for merging. E.g. you can override p-2 with !p-3. As long as you only ever need one level of overrides, this might be just enough.

2. Don't import the default config

When you use twMerge or extendTailwindMerge, the default config is used and therefore lands in the bundle. But you can tree-shake the config out of the bundle by using createTailwindMerge instead and create your own config. createTailwindMerge doesn't rely on the default config at all, so its bundle size is quite small (Bundlephobia says 1.6 kB out of the 6.3 kB).

const twMerge = createTailwindMerge(() => {
    return {
        …
        classGroups: {
            // You need to define all the class groups you want to use yourself now
        }
    }
})

[dcastil]

Linking to discussion I opened in Tailwind repo: tailwindlabs/tailwindcss#10348

[whytspace]

thank @dcastil! I already read about the custom config in the docs and will give it a try for now.

I am curious what the folks at tailwind have to say about the suggestion 😀

[Rinaldo]

Hi @dcastil, another approach that wouldn't require help from the tailwind team would be to break up the default config into core plugins. Right now the default config is all or nothing, you either get all the classGroups from the default with extendTailwindMerge or start from scratch with createTailwindMerge. Since tailwind-merge already supports merging configs, would it be feasible to export configs representing all the tailwind core plugins separately? Then users could specify a subset of commonly overridden plugins to reduce their bundle size.

It's common to override things like height, width, color, and some of the flex and grid properties. I would think it's less common to want to override properties like backdrop. The only issue would be if consumers get confused on which classes twMerge supports, though if they're using any tailwind plugins that's potentially already an issue.

[dcastil]

@Rinaldo that's an excellent idea! Thanks for suggesting! 🙏 I opened a new issue for this where I'll comment further on it. #228

[ivan-kleshnin]

Bundlephobia resource seems to be dead, since the end of 2023 😮‍💨
We should replace a link, for example with https://bundlejs.com/?q=tailwind-merge

[dcastil]

Agree, I'm also getting 502s for some while already. 😔 Created an issue in #397.

[TasseDeCafe]

I'm going to piggy-back on this conversation to avoid creating another thread.

I'm build a React app with Vite and Tailwind, with Shadcn as UI library. Shadcn imports tailwind-merge.

I used vite-bundle-visualizer to check the size of tailwind-merge in my bundle, and it comes out at 69kb. BundleJS says it should be around 21kb.

@dcastil, do you know where this discrepancy could be coming from? Thank you!

I haven't modified the code provided by shadcn, and this is the only use of tailwind-merge in my project:

import { twMerge } from 'tailwind-merge'

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

[whytspace]

@TasseDeCafe Thanks for joining the discussion, but I don't think that your problem is necessarily related.

do you know where this discrepancy could be coming from? Thank you!

vite-bundle-visualizer might be showing you wrong data: KusStar/vite-bundle-visualizer#8 and btd/rollup-plugin-visualizer#96
I just mention this, because I myself have had a similar issue with the plugin recently.

[TasseDeCafe]

Huh, that's interesting! Thank you. Is there any way to cross-check this information?

[whytspace]

Other than the lib authors themselves, I guess not:

• File sizes appear larger in visualizer than in reality KusStar/vite-bundle-visualizer#8 (comment)
• Reportes sizes don't match reality btd/rollup-plugin-visualizer#96 (comment)

my own learning from this was that you really can't rely on the actual numbers. the only thing I use these numbers now is to compare whether a file got smaller or bigger between two builds. The actual numbers don't really matter to me in that case.

If i really need the actual file sizes, I look at the files on disk after build

[dcastil]

@TasseDeCafe I didn't check @whytspace's links but I can imagine that the discrepancy comes from the library not being minified and therefore having a bigger size. I rely on people's bundlers taking over the job of minification since that yields better results in general.

Maybe the most accurate way to check the bundle size difference is to produce a bundle with tailwind-merge included and then another one where you replace the library with no-ops. Then you can directly compare the size differences.

I also have a CI job enabled on every PR which checks the minified and Brotli-compressed bundle size of tailwind-merge (latest one here which is around 6 kB).

[dcastil]

Note: Mentioned in #413 (comment)