Tailwind, Modules & Common Plugins

Tailwind as a PostCSS Plugin

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

Tailwind operates as a PostCSS plugin, generating an entire utility-class stylesheet from that small directive-based input — a concrete example of a plugin doing far more than simple property renaming, since plugins have full read/write access to the AST.

postcss-nested & CSS Modules

/* with postcss-nested, flattened at build time */
.card {
  padding: 16px;
  & .title { font-weight: bold; }
}

postcss-nested replicates Sass-style nesting via a plugin — illustrating PostCSS's composability. postcss-modules implements CSS Modules' class-name-scoping convention (avoiding global collisions) as a PostCSS transformation rather than a separate dedicated tool.

Common Plugin Roster

postcss-import inlines @import contents at build time (avoiding the extra blocking network request native @import triggers). postcss-custom-properties provides a static fallback value for browsers lacking native CSS variable support. cssnano minifies — typically the last step in a production pipeline.

Sass + PostCSS Together

A common real setup: Sass handles authoring-time convenience (variables, mixins), then PostCSS (chained after Sass compiles to plain CSS) handles output concerns — prefixing, minification — that aren't really about the authoring experience.

Why Composability Matters

Teams assemble exactly the transformations a project needs (prefixing, modern syntax, scoping, a utility framework) rather than being locked into one preprocessor's fixed feature set — valuable especially for design systems with unusual, specific requirements. The tradeoff: more chained plugins means more parse/transform passes, adding to build time.