tailwindcss: Dark mode "class" strategy doesn't work with CSS Modules and @apply

No plans to spend time on this one unfortunately, I would recommend just writing the CSS a bit more manually when in a CSS module (same way you had to with apply for hover and stuff in Tailwind 1):

.foo {
  @apply p-8;
  @apply bg-gray-100 text-gray-900;
}

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

I’d be open to reviewing a PR if someone has an idea for making this work but no plans to work on this myself.

@webtinax I’m late to the party here but I was able to get this working without it being too hacky in Next.js v12 using a portion of @tosuke’s answer. It may work in older Next.js versions, but I haven’t tried it.

next.config.js

module.exports = {
  webpack: config => {
    // Find the base rule that contains nested rules (which contains css-loader)
    const rules = config.module.rules.find(r => !!r.oneOf);

    // Interate over the found rules
    rules.oneOf.forEach(loaders => {
      // Focus on the the loaders that have an array of `use` statements
      if(Array.isArray(loaders.use)) {
        // Iterate over each of the loaders
        loaders.use.forEach(l => {
          // Only focus on loaders that are an object and have a `loader` property set to `css-loader`
          if(typeof l !== 'string' && typeof l.loader === 'string' && /(?<!post)css-loader/.test(l.loader)) {
            // If there are no module options originally set, skip this loader
            if(!l.options.modules) return;
            const { getLocalIdent, ...others } = l.options.modules;

            // Create a new options object with the `getLocalIdent` property set to a function
            l.options = {
              ...l.options,
              modules: {
                ...others,
                getLocalIdent: (ctx, localIdentName, localName) => {
                  // If the class name is `dark`, return it instead of hashing it
                  if(localName === 'dark') return localName;
                  // Otherwise, call the original function and return the value
                  return getLocalIdent(ctx, localIdentName, localName);
                }
              }
            };
          }
        });
      }
    });

    return config;
  }
};

I’ve had some errors with the solution from @KyleRoss . I needed to pass also the options parameter to the default getLocalIdent.

module.exports = {
  webpack: config => {
    // Find the base rule that contains nested rules (which contains css-loader)
    const rules = config.module.rules.find(r => !!r.oneOf);

    // Interate over the found rules
    rules.oneOf.forEach(loaders => {
      // Focus on the the loaders that have an array of `use` statements
      if(Array.isArray(loaders.use)) {
        // Iterate over each of the loaders
        loaders.use.forEach(l => {
          // Only focus on loaders that are an object and have a `loader` property set to `css-loader`
          if(typeof l !== 'string' && typeof l.loader === 'string' && /(?<!post)css-loader/.test(l.loader)) {
            // If there are no module options originally set, skip this loader
            if(!l.options.modules) return;
            const { getLocalIdent, ...others } = l.options.modules;

            // Create a new options object with the `getLocalIdent` property set to a function
            l.options = {
              ...l.options,
              modules: {
                ...others,
                getLocalIdent: (ctx, localIdentName, localName, options) => {
                  // If the class name is `dark`, return it instead of hashing it
                  if(localName === 'dark') return localName;
                  // Otherwise, call the original function and return the value
                  return getLocalIdent(ctx, localIdentName, localName, options);
                }
              }
            };
          }
        });
      }
    });

    return config;
  }
};

If I fix it, will you add it to the library so other users can benefit from it?

Depends on the complexity the solution introduces and the trade-offs necessary to make it work.

For what it’s worth you can change the selector that’s generated for dark mode classes which means you can use the selector CSS modules needs:

/** @type {import('tailwindcss').Config} */
module.exports = {
  darkMode: ["class", ":global(.dark)"],
  content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
};

The only issue here is if you are mixing regular CSS and CSS modules in the same project. If you’re doing that you’d need to use a separate config file for your CSS modules, which is easy in Tailwind now with the recently added @config directive.

I briefly looked into this this morning to see if it’s easy to detect when a CSS file is a module or not, but it doesn’t look like we have any way to tell other than checking if the file name ends in .module.css, but that’s not sufficient because scoped style blocks in Vue behave like CSS modules and those won’t have that file name, and based on comments above in Angular the file name would often be *.component.css instead.

We could support some sort of special directive or comment that you include in the file to configure it, like this:

@module;

.app {
  @apply bg-yellow-300 dark:bg-slate-900 py-12;
}

.headline {
  @apply text-4xl font-bold text-center text-slate-900 dark:text-yellow-300;
}

…but now we’re entering territory of significant additional complexity.

Again my real advice here taking a step back is just to not do this at all. Tailwind is meant to be used as utility classes in your HTML, that’s the intended workflow. The @apply feature is useful very occasionally in environments where it’s not common to componentize small things like buttons, but that’s it. If you’re using CSS modules, you’re probably not working on a Rails app or a Wordpress plugin where that is the case — you’re probably working with React where creating a Button.jsx file is the norm, and you should just use utility classes in that file.

I understand that a lot of people make heavy use of @apply to try and keep their HTML “clean” but that’s really not how the tool is meant to be used, and I think it sends a bad message to invest into making it easier to use the tool the wrong way.

@tosuke @phuctm97 here is my solution: https://github.com/tailwindlabs/tailwindcss/discussions/3109#discussioncomment-335950

The workaround would still break certain aspects of the application tough. What we want is to get a tailwind utility with the dark:prefix to not be resolved to .dark when in a css-module but instead to be resolved to :global(dark). If someone choses to use a .dark class in his code, it should still be able to resolve regardless of tailwind‘s presence.

@adamwathan

.foo {
  @apply p-8;
  @apply bg-gray-100 text-gray-900;
}

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

And how is it in a nested css (or scss). For example:

.sections {
  display: flex;
  flex-direction: column;
  row-gap: theme('space.12');
  > section {
    display: flex;
    flex-direction: column;
    row-gap: theme('space.6');
    > header {
      > p {
        @apply text-body-color dark:text-white; /* <<<------- SEE HERE ----- */
      }
    }
    > div {
      display: grid;
      @apply grid-cols-1 gap-6 md:grid-cols-2 xl:grid-cols-3;
    }
  }
}

If you’re using angular 2+ and you have this issue: just add encapsulation: ViewEncapsulation.None, to your component, as it follows:

@Component({
  selector: 'app-calendar',
  templateUrl: './calendar.component.html',
  styleUrls: ['./calendar.component.css'],
  encapsulation: ViewEncapsulation.None,
})

And it gonna work like a charm 😄

This here is the typical “tailwind” negligence. They brag about “Rapidly build modern websites” in their website, and then refuse to listen to actual developers describing actual needs.

Yeah I agree on this one , this needs described on their documentation. I did wasted couple of hours checking why this wasn’t working on the first place. Probably just adding to their documentation the :global approach will be enough for now

This here is the typical “tailwind” negligence. They brag about “Rapidly build modern websites” in their website, and then refuse to listen to actual developers describing actual needs.

The fact that both dark: variant is suggested in documentation, as well as @apply is suggested in documentation suggests these two should work together.

When you have two features in a library, people will want to use them together.

There is no reason this shouldn’t be added to library, other the the fact that there are “no plans”.

Workaround

Suppress renaming of .dark selectors. If you use css-loader, you can use getLocalIdent to suppress renaming.

{
  loader: 'css-loader',
  options: {
    module: {
      getLocalIdent: (_context, _localIdentName, localName) => {
        if (localName === "dark") return "dark";
      },
    }
  }
}