Programming Tutorials

  You’ve upgraded your dependencies to Tailwind CSS v4, expecting the promised performance boost from the new Oxide engine. Instead, your build finishes instantly but your styles are missing, or your console is flooded with   Unknown at rule @tailwind   errors. Tailwind v4 represents a paradigm shift from a JavaScript-configured utility library to a native CSS-first build tool. The breakage occurs because v4 deprecates the proprietary directives and JavaScript configuration reliance you’ve used for years. Here is why your build is breaking and the rigorous path to fixing it. The Root Cause: Architecture Shift In v3, Tailwind relied on PostCSS to scan your  tailwind.config.js , generate an Abstract Syntax Tree (AST), and inject CSS via the  @tailwind  directives ( base ,  components ,  utilities ). In v4, the architecture is inverted: Native CSS Resolution:  The core directives are replaced by standard CSS  @import  statements. No De...

  You upgraded to Tailwind CSS v4 to leverage the new Oxide engine, expecting a silent performance boost. Instead, your build pipeline is screaming about unresolved classes, or worse—the build succeeds, but your custom components relying on   @apply   have completely lost their styling. The issue isn't just a syntax change; it is an architectural inversion. Tailwind v4 moves the source of truth from JavaScript ( tailwind.config.js ) to CSS. This shift fundamentally alters how the engine resolves custom values and processes the  @apply  directive. The Root Cause: The Death of the JavaScript AST In v2 and v3, Tailwind functioned as a JavaScript-heavy PostCSS plugin. When you defined a color in  tailwind.config.js , the engine built a massive internal JavaScript object representing your theme. When you used  @apply bg-primary , Tailwind looked up  primary  in that JS object to generate the CSS. In v4, the engine is native (Rust). It does not wan...