Summary
This incident centers on StencilJS failing to recognize @tailwindcss/postcss as a valid PostCSS plugin, even though the configuration appears correct. The failure stems from a subtle but critical mismatch between Tailwind CSS v4’s new PostCSS architecture and Stencil’s PostCSS plugin loader, which still expects the older plugin format.
Root Cause
The underlying issue is that Tailwind CSS v4 no longer exposes a traditional PostCSS plugin.
Stencil’s PostCSS integration expects plugins to be functions, but @tailwindcss/postcss in Tailwind v4 is not a PostCSS plugin—it is a compatibility shim that requires Tailwind’s new architecture.
Key points:
- Tailwind v4 removed the classic PostCSS plugin entry point
- Stencil’s PostCSS wrapper still expects legacy PostCSS plugin signatures
- The plugin string
'@tailwindcss/postcss'resolves to a module that does not export a PostCSS plugin function - PostCSS throws: “is not a PostCSS plugin at Processor.normalize”
Why This Happens in Real Systems
This class of failure is common when:
- Frameworks evolve faster than their plugin ecosystems
- Build tools assume stable plugin interfaces
- Libraries introduce breaking architectural changes without backward compatibility
- Plugin loaders rely on runtime type checks that fail silently until execution
Real-World Impact
Teams often experience:
- Build failures that appear unrelated to their code
- Confusing error messages that point to PostCSS internals
- Broken CI pipelines after dependency upgrades
- Lost engineering time debugging what looks like a configuration typo
Example or Code (if necessary and relevant)
Below is an example of a correct Tailwind v4 setup for StencilJS using the new Tailwind CLI instead of PostCSS:
// stencil.config.ts
import { Config } from '@stencil/core';
export const config: Config = {
globalStyle: 'src/global/tailwind.css',
};
And the Tailwind entry file:
/* src/global/tailwind.css */
@import "tailwindcss";
How Senior Engineers Fix It
Experienced engineers recognize that the solution is not to fix the plugin, but to stop using PostCSS for Tailwind v4 entirely.
They typically:
- Remove all PostCSS Tailwind plugin references
- Use the Tailwind CLI or Tailwind’s new build pipeline
- Ensure Stencil consumes the generated CSS normally
- Lock dependency versions to avoid accidental breaking upgrades
Senior engineers also check:
- Tailwind’s migration guides
- Changelogs for breaking changes
- Whether the plugin ecosystem has caught up
Why Juniors Miss It
Junior engineers often:
- Assume “plugin not found” means a path or syntax error
- Expect PostCSS plugins to behave consistently across versions
- Don’t realize Tailwind v4 abandoned the PostCSS plugin model
- Focus on fixing the configuration instead of questioning the architecture
- Miss subtle clues in error messages like “not a PostCSS plugin”
They tend to debug the wrong layer—the configuration—instead of the real issue—the plugin no longer exists in the expected form.