Why React components from npm render unstyled with Tailwind v3

Oğuzhan Ayyıldız — Wed, 07 Oct 2026 11:43:14 +0000

Install a React component library, import a Button, render it. The label shows up and the click handler fires, but the thing looks like a gray browser default. The console is quiet and the build is green.

I reproduced this in clean projects while working on MoonUI, a component library built on Radix and Tailwind. The components were not broken. My Tailwind setup just had no idea they existed, and then no idea what their colors meant. Those are two separate problems with two separate fixes, and a third small trap sits right behind them.

Everything here is the Tailwind v3 config format. I have not tried any of it on v4.

Tailwind only writes the classes it can see

Tailwind v3 does not ship a giant stylesheet. At build time it reads the files listed under content, collects anything that looks like a class name, and generates CSS for those names only. A library that ships its Tailwind classes inside compiled JavaScript puts them in node_modules, and your config does not look there unless you tell it to.

So the first fix is a single extra glob:

// tailwind.config.js
module.exports = {
  content: [
    "./src/**/*.{js,ts,jsx,tsx,mdx}",
    "./node_modules/@moontra/moonui/dist/**/*.{js,mjs}",
  ],
};

Point it at dist, because that is what your bundler actually imports. The source folder is not the thing that gets scanned in your build.

You could ask why the library's own preset doesn't add this path for you. It leaves content out on purpose. Paths depend on where your config lives and how your package manager lays out node_modules, and a wrong guess produces no error at all. One explicit line in your own config is easier to debug than a guess hidden inside a preset.

The class exists, but the color does not

Once the glob is in, something changes: padding and rounded corners show up. In my clean-project run the button went from a 24px-high element with no padding to a 40px-high one with 16px of horizontal padding. The background, though, stayed transparent.

That is because a themeable library rarely hardcodes a color. A button asks for bg-primary, and Tailwind has to be told what primary means. Two pieces carry that meaning. The preset maps Tailwind's theme keys onto CSS variables, for example primary to hsl(var(--primary) / <alpha-value>). A token stylesheet then defines --primary and the rest, for light and dark.

// tailwind.config.js
module.exports = {
  presets: [require("@moontra/moonui/tailwind-preset")],
  content: [
    "./src/**/*.{js,ts,jsx,tsx,mdx}",
    "./node_modules/@moontra/moonui/dist/**/*.{js,mjs}",
  ],
  plugins: [require("tailwindcss-animate")],
};

The tailwindcss-animate plugin is in there because Radix-driven components such as the dialog use animate-in and fade-in-0 for their open and close states. It is not a dependency of the package, so you install it yourself.

The part that is easy to miss: after adding only the preset, I checked the generated CSS. The .bg-primary rule was there. The --primary: definition was not. The rule pointed at a variable nobody had defined, so the browser threw the declaration away and the background stayed transparent. The preset is the map and the tokens are the territory, and a map alone gets you nowhere.

Loading the tokens

Importing the token file is the last step. The package exposes it as @moontra/moonui/tokens.css, and the import that worked in every setup I measured is the JavaScript one:

// src/main.jsx (Vite) or app/layout.tsx (Next.js)
import "./globals.css";
import "@moontra/moonui/tokens.css";

/* globals.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

I tested this on @moontra/moonui 6.30.3 from npm with Tailwind 3.4, in three setups: Next.js 15 with its default PostCSS config, Next.js 15 with postcss-import added, and Vite 5. In all three, the production build passed and the Button computed a real background color (rgb(16, 103, 244)).

The CSS version is less uniform, and I would rather say so than pretend otherwise. Writing @import "@moontra/moonui/tokens.css" in your stylesheet works on default Next.js and on Vite. It fails on Next.js once postcss-import is in the pipeline, with a "Failed to find" error. The reason is that postcss-import does not read a package's exports map, while the resolvers built into Next and Vite do. If you already use postcss-import, the JavaScript import is the way around it.

The longer physical path, @moontra/moonui/src/styles/tokens.css, is not listed in exports. It builds only in the postcss-import case and gets rejected as "not exported" elsewhere. I would not use it.

Load the tokens once, by one of these routes. I did not measure Tailwind v4 or webpack setups that are not Next.js, so I won't say anything about them.

The order I check things in now

When a package renders unstyled under Tailwind v3, I go through it in this order, because each step produces a different symptom:

No padding, no radius, a bare browser button: the package's dist folder is missing from content.
Layout looks right, background transparent: check that the preset is in presets, then check that the CSS variables are defined anywhere in your bundle.
Layout and color are fine, but dialogs and popovers appear with no motion: the animate plugin is missing.

Looking at the computed style in devtools settles most of this in under a minute. If background-color resolves to rgba(0, 0, 0, 0) and the .bg-primary rule exists, you are on step two.

The code above comes from the free MIT-licensed package behind MoonUI, at https://github.com/moonuidotdev/moonui. If you maintain a Tailwind-based library, do you ship a compiled stylesheet instead of asking people to edit their config, and what made you choose that?

DEV Community: Oğuzhan Ayyıldız

Why React components from npm render unstyled with Tailwind v3

Tailwind only writes the classes it can see

The class exists, but the color does not

Loading the tokens

The order I check things in now