Fix CSS conflicts between dev and prod with :where() and strict chunking

The moment a CSS bug surfaces only in production, it’s time to dig deeper. What appears as a styling inconsistency can unravel into a fundamental misunderstanding of how your toolchain shapes the final output. One such case unfolded recently when a form label’s width rendered correctly in development but collapsed in production, revealing a hidden dependency on source order that no one had accounted for.

The symptom: identical code, different results

A production release shipped with a feature that worked flawlessly in the development environment. Yet, on deployment, a form label’s width collapsed from an expected 20.75rem down to 11rem. The discrepancy was immediately visible, but the cause wasn’t.

At first, the fix seemed trivial. Adding !important to the rule restored the width, but it masked the real issue. A bug that behaves differently between environments often returns later in a different file, disguised as a new problem. Rolling back the emergency patch was the first step toward understanding what had truly gone wrong.

The root cause: CSS specificity and source order

The label in question carried two CSS classes from separate modules:

• .label from a shared component, setting width: 20.75rem
• .fieldLabel from a consumer page, setting width: 11rem

Both rules had the same specificity (0,1,0), so the browser deferred to source order. In development, the consumer’s rule appeared later in the stylesheet and won. In production, the shared component’s rule appeared later and took precedence. The same codebase, two different outcomes—all because a build tool reordered the CSS rules.

How to confirm the ordering mismatch

Debugging began by inspecting the compiled CSS. Running a build and grepping the output revealed the culprit:

npm run build
grep -E "11rem|20.75rem" out/_next/static/chunks/<the-file>.css

Both rules existed in the same chunk file, but their order had flipped. DevTools confirmed the override: the .fieldLabel rule was struck through, while the .label rule applied. Chrome even displayed a tooltip explaining that the later rule in the stylesheet had overridden the earlier one. The browser was functioning as designed. The mistake had been assuming source order was predictable.

Why development and production differ

In development, Next.js injects each CSS Module as a separate <style> tag, in the exact order JavaScript imports the modules. Since imports resolve depth-first, the consumer’s module—being a leaf node—typically appears later, naturally overriding shared defaults. This behavior feels intuitive and reliable—until it isn’t.

Production builds, however, bundle CSS Modules into chunk files using Turbopack and Lightning CSS. Turbopack attempts to preserve import order, but when a shared module is reachable through multiple import paths, the bundler must choose one order. That choice may not match development’s runtime injection, turning source order into a hidden variable that alters layout unpredictably.

A clean fix with :where()

The real solution wasn’t to fight the cascade but to redesign how shared styles interact with overrides. Enter :where(), a relatively new CSS pseudo-class that resets specificity to zero. By wrapping the shared component’s default rule in :where(), its specificity drops to (0,0,0). Any downstream override, even a single class, now trumps it automatically:

:where(.label) {
  width: 20.75rem;
  padding-top: 0.5rem;
}

With this change, the shared component’s default values become fallback options. They apply only when no other rule overrides them. There’s no need to rely on source order, and no need for !important or overly specific selectors like .root .fieldLabel. It’s a cleaner, more maintainable pattern—especially for shared UI libraries.

Adding a safeguard: strict CSS chunking

Even after fixing the within-chunk ordering issue, another risk remained: Next.js merging CSS across modules in unpredictable ways. To prevent this, enabling the experimental.cssChunking: 'strict' option in next.config.ts adds a guardrail:

experimental: {
  cssChunking: 'strict',
}

This setting tells Next.js to stop reordering CSS files across modules. While it doesn’t resolve within-chunk ordering, it prevents cross-module merges from silently altering styles. For teams that have encountered version of this bug, it’s a simple but effective mitigation.

The takeaway: trust, but verify

A bug that behaves differently in development and production is rarely just a bug. It’s often a sign that a core assumption—like source order—has been quietly violated. The fix isn’t to double down on fragile workarounds, but to redesign the interaction between shared and consumer styles so they coexist predictably.

Using :where() for shared defaults and enabling strict CSS chunking turns unpredictable overrides into intentional overrides. The result is more reliable styling, fewer surprises on deployment, and cleaner component contracts for the future.