Tailwind classes do not compile as expected when using CSS-Modules and :dark prefix

[trm217]

Describe the problem:

I was updating my website to utilize the tailwind-configuration darkMode: 'class' instead of darkMode: 'media' and noticed an unexpected behavior. In my project, I use TailwindCSS 2.0 and CSS-Modules.

When given the following code inside a CSS-module

.informationName {
    @apply font-black;
    @apply text-black;
    @apply dark:text-white;
}

compiles to the following code when using the darkMode: 'media' configuration

.PortraitSection_informationName__1iAOK {
    font-weight: 900;
    --tw-text-opacity: 1;
    color: rgba(0, 0, 0, var(--tw-text-opacity))
}

@media (prefers-color-scheme: dark) {
    .PortraitSection_informationName__1iAOK {
        --tw-text-opacity: 1;
        color: rgba(255, 255, 255, var(--tw-text-opacity))
    }
}

In this case, the compiled CSS is exactly what one would expect.

However with the darkMode: 'class' configuration the following CSS get's compiled

.PortraitSection_informationName__1iAOK {
    font-weight: 900;
    --tw-text-opacity: 1;
    color: rgba(0, 0, 0, var(--tw-text-opacity))
}

.PortraitSection_dark__34kkQ .PortraitSection_informationName__1iAOK {
    --tw-text-opacity: 1;
    color: rgba(255, 255, 255, var(--tw-text-opacity))
}

I doubt that this was meant to happen since this breaks the darkMode: 'class' configuration completely when using CSS-Modules

It's obvious that this problem is caused by using CSS-Modules but unless there is a way around it CSS-Modules and the darkMode: 'class' configuration are incompatible.

[adamwathan]

Yeah nothing we can really do about this on our end I'm afraid — CSS modules will automatically scope all CSS inside of it like you're seeing. Whatever solution you come up with here will probably be outside of the scope of Tailwind itself. I don't know how you can write a partially global/partically scoped selector with CSS modules in general, like if you wrote this by hand:

.informationName {
    font-weight: 900;
    color: #000;
}
.dark .informationName {
  color: #fff;
}

...the .dark class would still get mangled by CSS modules right? So I'm not sure if CSS modules is even compatible with the concept of a distant parent class modifier like this.

No plans to do anything in Tailwind to change this behavior but will transfer this to our discussions in case others want to chime in with ideas.

[trm217]

I by no means meant to insult TailwindCSS by saying it's not viable to use inline CSS in large scale component-based projects.
I love TailwindCSS ever since I started using it, it has given me great flexibility in all my new projects! 🙏☺
I really appreciate TailwindLabs and all contributors for developing it. 💯
I am sorry for my poor choice of words.

However, I know many FE-developers that are simple completely against an inline CSS approach. This is also what made it rather hard for me to convince my colleagues to use Tailwind in our projects. Most of the time I managed to convince them by showing the approach of using the @apply syntax.

Now regarding the problem, there is a way to scope CSS-class selectors globally inside a CSS-Module. I'll provide an example:

If I want to define a CSS-module class with a preceding global CSS-class one could use the :global syntax provided by CSS-Modules.

Here an example

// CSS inside the CSS-Module
:global(.dark) .test {
    @apply text-gray-100;
}

// CSS generated by PostCSS
.dark .PortraitSection_test__14rKg {
    --tw-text-opacity: 1;
    color: rgba(245, 245, 245, var(--tw-text-opacity))
}

If TailwindCSS was to generate the class :global(.dark) instead of .dark (of course this should only happen when the TailwindConfig uses "class" for it's darkMode configuration) whenever the ":dark" prefix was used inside a CSS-Module (I suppose this could be checked in the PostCSS plugin during build time by matching a regex against the input filename?) I believe the compatibility between TailwindCSS darkMode and CSS-modules would be granted.

What do you think of this approach?

[trm217]

I just managed to get the approach I explained above somewhat working. By adapting tailwindcss/lib/substituteVariantsAtRules.js.
By updating the code like this:

if (config.darkMode === 'class') {
    const modified = modifySelectors(({
        selector
    }) => {
        return (0, _buildSelectorVariant.default)(selector, 'dark', separator, message => {
            throw container.error(message);
        });
    });
    modified.walkRules(rule => {
        // Do this if the rule's source is a CSS-module file
        if ( /* TODO: Check if source.input.file of rule is a .module.css */ ) {
            rule.selectors = rule.selectors.map(selector => {
                return `${(0, _prefixSelector.default)(config.prefix, ':global(.dark)')} ${selector}`;
            });
        } else {
            rule.selectors = rule.selectors.map(selector => {
                return `${(0, _prefixSelector.default)(config.prefix, '.dark')} ${selector}`;
            });
        }

    });
    return modified;
}

I checked and when using ':global(.dark)' the modules indeed do work with the global dark-mode scope as expected.
The only thing missing is to figure when to apply .dark and when :global(dark), I assume one could somehow figure out the original file of the css via the sourcemap? Am I right with that assumption?

[rikusen0335]

I also need this. Like using Tailwind with Next.js and CSS Modules doesn't work as I expected.

Also,

:global(.dark) .test {
    @apply text-gray-100;
}

is working for now, but I'm too lazy to writing all of classes like :global(.dark) .test. I hope Tailwind would have the function. This will makes better.

[trm217]

@rikusen0335 Yeah that's the one way to get around it, but its breaks the use of Tailwind Darkmode in two ways:

1. You will need two rule sets to apply dark-mode so the dark: prefix is not usable in that case.
2. If you now choose to go back to media query-based dark mode, you will need to rewrite all styles where you used :global(dark) because this is incompatible with the media query approach. That for using the dark: prefix is the logical way around it.

Code to show how to workarround issue 1.

.test {
   @apply bg-white;
   @apply text-black;
}

:global(.dark) .test {
   @apply bg-gray-900;
   @apply text-white;
}

```

[rikusen0335]

@trm217 Yes I'm now trying like that.

(Don't mind dark:bg-black)

As you said this breaks use of Tailwind, and we should fix this after anything changes. So I don't want to use this scheme.