Framework Guides

Purpose and Scope

The framework guides page is the routing layer between Tailwind CSS installation choices and the environment a reader actually uses. The official documentation presents Tailwind as a zero-runtime compiler: it scans HTML, JavaScript components, and template files for class names, generates the matching styles, and writes static CSS. The framework guide list then names environments like Next.js, Laravel, Nuxt, SolidJS, SvelteKit, Gatsby, Angular, Rails, Astro, Phoenix, Parcel, Rspack, and others. This page explains how that reader-facing list maps back to the shared packages in this repository rather than treating every framework as a separate compiler.

Sources: packages/tailwindcss/src/index.ts, packages/tailwindcss/package.json

The key idea is that framework-specific installation pages mostly differ in how they connect Tailwind to a build pipeline, not in what Tailwind is. Whether a project is a React framework, a PHP framework, a Vue meta-framework, or a bundler-driven app, the end state is still an input CSS file processed by the Tailwind compiler and a generated stylesheet consumed by the application. The repository reflects that split: the tailwindcss package owns the compiler and public CSS entry points, while runtime-specific packages expose ways to invoke it from Node, the CLI, or the browser.

Sources: packages/tailwindcss/src/index.ts, packages/@tailwindcss-node/src/index.ts, packages/@tailwindcss-cli/src/index.ts, packages/@tailwindcss-browser/src/index.ts

Relevant Source Files

• packages/tailwindcss/src/index.ts — Core compiler source for parsing Tailwind CSS input, loading stylesheets and modules, tracking compiler features, and building utilities from class candidates.
• packages/tailwindcss/package.json — Public package metadata and export map for the main tailwindcss package, including CSS entry points such as index.css, preflight.css, theme.css, and utilities.css.
• package.json — Root workspace scripts that show how the monorepo builds, tests, and runs representative playground tasks such as Vite and Next.js development commands.
• packages/@tailwindcss-browser/src/index.ts — Browser runtime used by the Play CDN style workflow, including style tag discovery, compiler creation, virtual Tailwind stylesheet loading, and scheduled rebuilds.
• packages/@tailwindcss-cli/src/index.ts — CLI command entry point that routes tailwindcss, tailwindcss build, help output, and canonicalization behavior.
• packages/@tailwindcss-node/src/index.ts — Node-facing package barrel that exports compile, optimization, instrumentation, path normalization, source-map helpers, and ESM cache hook behavior.

Core Primitives Behind Framework Guides

The first primitive is the core compiler exposed by the tailwindcss package. In source, compile options include a base path, an optional source file path, polyfill controls, and loader hooks for modules and stylesheets. The CSS parser records feature flags for constructs such as @import, @apply, JavaScript plugin compatibility, theme(...), utilities, variants, and @theme. Framework guides can therefore focus on where to put a CSS file and how to run a build step because the compiler already centralizes the Tailwind-specific interpretation of directives, theme declarations, variants, imports, and utility generation.

Sources: packages/tailwindcss/src/index.ts

The second primitive is the published package contract. The tailwindcss package export map exposes the main package entry, compatibility helpers like colors and default theme, the plugin entry point, and direct CSS assets for index, preflight, theme, and utilities. That matters for framework guides because modern build tools commonly resolve package exports rather than hard-coded file paths. A framework integration can import the main CSS entry, use plugin compatibility APIs, or reference the segmented CSS files while still depending on a stable npm package boundary.

Sources: packages/tailwindcss/package.json

The third primitive is the execution adapter. In a framework build, Tailwind usually runs inside a tool-controlled process: a dev server, production build, PostCSS pipeline, Vite plugin, or command-line watcher. The requested source set shows three adapter shapes. The Node package re-exports lower-level compile and optimization utilities for integrations. The CLI package parses commands and flags for direct builds. The browser package creates a compiler in the page for CDN-style workflows. These are different invocation models over the same conceptual task: transform Tailwind-aware CSS plus detected class candidates into final CSS.

Sources: packages/@tailwindcss-node/src/index.ts, packages/@tailwindcss-cli/src/index.ts, packages/@tailwindcss-browser/src/index.ts

System-to-Code Mapping

Reader path	Repository-backed capability	Source signal
Framework guide for a build-tool-backed app	Shared compiler understands Tailwind CSS features and stylesheet/module loading	packages/tailwindcss/src/index.ts
Framework guide using package imports	Published exports define JavaScript and CSS package entry points	packages/tailwindcss/package.json
Framework or integration running in Node	Node package exports compile, optimize, instrumentation, source-map, and path helpers	packages/@tailwindcss-node/src/index.ts
Direct installation fallback	CLI entry point supports root build behavior, build, help, and canonicalization	packages/@tailwindcss-cli/src/index.ts
CDN or no-build experimentation	Browser runtime watches Tailwind style tags, creates a compiler, and injects generated CSS	packages/@tailwindcss-browser/src/index.ts
Contributor validation and examples	Root scripts run workspace builds, tests, integration tests, UI tests, and playground dev commands	package.json

The official framework list should be read as a set of recommended recipes, not as evidence that every framework needs a custom Tailwind engine. For example, a Next.js or Nuxt guide can integrate through a framework’s preferred build layer, while a Rails, Phoenix, Symfony, or Laravel guide may emphasize where generated CSS enters that framework’s asset pipeline. A Parcel or Rspack guide is closer to a bundler setup. The shared repository mapping remains stable across those differences: use the public package, invoke Tailwind through an adapter, and let the compiler perform scanning-driven utility generation.

Sources: packages/tailwindcss/package.json, packages/tailwindcss/src/index.ts

Execution Flow for a Framework Setup

A typical framework guide starts by asking the reader to install the relevant Tailwind packages, add a Tailwind import to project CSS, and wire that CSS file into the framework’s build process. Once the build tool invokes Tailwind, the compiler parses the input CSS and substitutes imports before processing Tailwind-specific constructs. The parser stores feature information so later phases know whether utilities, variants, @theme, @apply, plugin compatibility, or theme functions were used. This keeps framework instructions short while preserving sophisticated behavior inside the compiler.

Sources: packages/tailwindcss/src/index.ts

When a guide falls back to the CLI, the @tailwindcss/cli entry point provides a direct execution path. Its root command accepts build options, recognizes the explicit build command, prints help when invoked interactively or with --help, and rejects unknown non-flag commands with usage output. This path is especially useful for frameworks whose asset pipeline can run an external command or for minimal projects that do not need a dedicated plugin package. It is also the most concrete bridge from documentation instructions to a local build script.

Sources: packages/@tailwindcss-cli/src/index.ts

When a guide points readers to CDN-style experimentation, the browser package shows the alternate model. It scans the document for style tags whose type is text/tailwindcss, concatenates their contents, injects @import 'tailwindcss'; when the user has not supplied an import, and creates a compiler with virtual stylesheet loaders for Tailwind’s index, preflight, theme, and utilities CSS. It tracks seen classes and schedules builds so the page can update without a conventional Node build pipeline.

Sources: packages/@tailwindcss-browser/src/index.ts

API and Package Reference Signals

For framework authors and integration maintainers, the most important public boundaries are the tailwindcss export map and the @tailwindcss/node barrel exports. The main package advertises style, TypeScript, CommonJS, and ESM targets for the package root, plus named subpath exports for plugin, defaultTheme, colors, flattenColorPalette, and the CSS files. The Node package then collects the operational helpers that adapters need: compile behavior, optimization, instrumentation, normalized paths, source maps, and environment access. Framework guides should prefer these package boundaries over reaching into private compiler internals.

Sources: packages/tailwindcss/package.json, packages/@tailwindcss-node/src/index.ts

The root workspace scripts provide contributor and operator signals rather than end-user setup steps. They show that the repository is organized around Turbo-powered builds and development, Rust and Vitest test coverage, integration tests rooted under integrations, UI tests for the main and browser packages, and named playground commands for Vite and Next.js. Those scripts help explain why the documentation can recommend concrete framework and build-tool paths: the monorepo has separate validation layers for core behavior, integrations, and example playground workflows.

Sources: package.json

Choosing the Right Guide

Choose a named framework guide first when the official docs list your environment, because those pages encode framework-specific file locations, package-manager commands, and build conventions. If your framework is not listed, choose the closest execution adapter: a Vite-style plugin for Vite-compatible projects, a PostCSS pipeline where the framework already runs PostCSS, the CLI where external build commands are natural, or Play CDN for prototypes. From this page, continue to using-vite, using-postcss, tailwind-cli-installation, or play-cdn depending on which adapter your framework can run most cleanly.