Frameworks

So far every build used the Tailwind command line. Real projects run Tailwind inside a bundler or a framework, and the integration has the same three jobs everywhere: read your CSS entry file, scan the project for classes, and put the result in the page. This chapter wires Tailwind into seven toolchains, runs each one for real, and then deals with the problems that appear once it is in: style blocks in components, a flash of the wrong theme when the server renders the page, and shared code in a monorepo.

Which Package for Which Tool

In every case the CSS entry file is the same one line, @import "tailwindcss";, plus your @theme. In every case I built a small page with a few text utilities and checked that the built CSS contained the rules. Each of the seven worked on the first correct configuration; the surprises are below.

Vite

Two lessons. A production build minifies the CSS without being asked (the CLI needed --minify, chapter 1). And the development server scans your HTML as you edit it, so a new class appears without restarting anything. I stopped the server by finding the process listening on the port and ending only that one.

Astro, Next.js, SvelteKit and React Router

These four use the same two packages in four different places. All four built without errors:

(The sizes are for different pages, so do not compare them with each other; they only show that real CSS came out.) Three things I found by running them rather than reading about them:

• SvelteKit 3 no longer reads svelte.config.js. My first attempt used the file I remembered and the build stopped with SvelteKit error: config_file_unsupported: the message says to pass the configuration to the sveltekit(...) plugin in the Vite config, which is what the table shows. Order in the plugin list: I put tailwindcss() before sveltekit(); I did not test the reverse.
• Next.js wrote the theme colour twice. The same --color-brand: oklch(0.55 0.2 260) came out as oklch(55% .2 260) in Vite, Astro and SvelteKit, but in the Next.js build as #1c69e3 followed by @supports (color:lab(0% 0 0)) { :root,:host { --color-brand: lab(45.7354% 14.1968 -69.775) } }. The two tools use different browser targets when they post-process the CSS. I did not trace the setting that causes it; if exact colour matters across tools, compare their built output.
• Next.js warned about my folder layout. It printed We detected multiple lockfiles and selected the directory of C:\lwdj\tw2\package-lock.json as the root directory, because my scratch project sat inside another one. That is a monorepo question in disguise; see the last section.

webpack

The webpack integration is a loader, not a plugin. It goes last in the use list (loaders run right to left), after css-loader and the extraction plugin:

The loader scans from the working directory, so run webpack from the project root (or set base). The page's classes were found in src/index.js without any extra configuration.

Component Styles: @apply and @reference

The most common v4 integration error comes from the framework's own style blocks (Vue, Svelte, Astro) and CSS modules. Each block is compiled as its own stylesheet, so it cannot see your theme or utilities. This is what happened in a Vue single-file component:

The fix is @reference, which imports your main stylesheet for use by @apply without copying any of it into the output. I measured the alternatives with the same component:

The same error and the same fix applied to a CSS module in plain Vite (._btn_16twv_2{…} came out). Astro and SvelteKit style blocks with @reference "../styles/global.css" built and produced .btn[data-astro-cid-…] and .btn.svelte-… rules; the relative path is from the component, and my first attempt with the wrong depth failed with Can't resolve.

Server Rendering and the Flash of the Wrong Theme

Chapter 2 switched themes with a data-mode attribute. If the server renders the page and your application code sets the attribute later, a visitor who chose dark sees a light page first. I measured it with three pages that differ only in when the attribute is set, saved preference "dark", sampling the background on every animation frame:

The answer is a small classic script in the document head that sets the attribute before the page paints. The module version was deferred by the browser even though it was inline, so its first frame was light. How that looks in two frameworks I built:

Astro rewrote my plain <script> into <script type="module">, which is the deferred kind, so use is:inline to keep it a classic script. In Next.js, a script that changes <html> before React hydrates makes the server HTML and the browser's disagree, and React says so; suppressHydrationWarning on that one element is the intended answer and it removed the message. I did not run SvelteKit (the equivalent place is the inline script in src/app.html) or React Router (a script in the root layout) for this, so treat those two as untested.

Monorepos and Shared Theme Packages

A monorepo splits code into packages: here a theme package (tokens), a ui package (components that carry Tailwind classes) and an app that uses both through npm workspaces. Two things break silently, and I measured both with the same built app:

Version 1: the shared button's classes live outside the app's folder and the scanner does not follow the workspace link in node_modules, so none of them were generated. Version 3: without the theme import the tokens do not exist, so even the app's own text-accent disappeared. Neither raised an error. The rules: add @source for every workspace package whose files contain classes (the path is relative to the CSS file), and import the shared theme CSS in every app, once. The theme package is just a CSS file exposed through the package's exports, which makes it a convenient place to put the semantic tokens from chapter 2 for several apps.

Hands-On Exercises