Blog | loke.dev

Are your Next.js styles working perfectly in development but breaking in production? Do your carefully crafted CSS specificity rules suddenly stop working after deployment? You might be experiencing the notorious Next.js CSS resolution order bug that has been frustrating developers since the introduction of the App Router.

In this comprehensive guide, I'll explain exactly what this bug is, how it affects your projects, and provide step-by-step solutions to fix it once and for all.

What is the Next.js CSS Resolution Order Bug?

The issue, tracked as vercel/next.js#64921, involves how Next.js handles CSS ordering when bundling styles for production builds with the App Router. This bug specifically impacts projects that use a combination of global styles and component-level CSS (including CSS modules).

Here's the exact sequence that triggers the bug:

In development mode (next dev), CSS is loaded in the expected order, with component-level styles correctly overriding global styles when they have the same specificity.
However, in production builds (next build and next start), Next.js inconsistently changes the order of CSS resolution, often placing global styles after component-level styles.
This causes global styles to unexpectedly override component styles in production, even when they have the same specificity, breaking the fundamental CSS cascade principle.

The result? Styling that looks perfect during development suddenly breaks in production, making debugging extremely difficult and time-consuming.

Why This Bug Impacts Your Development Workflow

This bug is particularly problematic for modern Next.js applications because:

It creates environment inconsistencies: Styles work in development but break in production
It undermines CSS best practices: Carefully planned CSS specificity becomes unreliable
It affects complex component hierarchies: Especially when components are used in both layouts and pages
The errors are visual and difficult to diagnose: No console errors appear to help debugging

The issue can cause significant visual regressions in production while everything looks perfect locally, leading to confusion, wasted debugging time, and delayed deployments.

Real-World Example: How This Bug Breaks Your Styles

Let's look at a concrete example to understand the impact:

Imagine you have a global style in your app/globals.css file:

.button {
  background-color: blue;
  color: white;
}

And a component-level style in app/components/Button/styles.module.css:

.button {
  background-color: red;
  color: white;
}

In your component:

import styles from './styles.module.css'
 
export function Button() {
  return <button className={styles.button}>Click me</button>
}

During development, your button appears red as expected (component styles override global styles). But after deployment to production, the button suddenly appears blue because the global styles are being applied last, overriding your component styles.

How to Fix the Next.js CSS Resolution Order Bug: Step-by-Step Solutions

While the Next.js team is aware of this issue, it hasn't been fully resolved yet. Here are several effective workarounds:

Solution 1: Use CSS Layers to Control Specificity

The most robust solution is to use CSS layers to explicitly control the order of your styles:

Create a PostCSS plugin to wrap node_modules CSS in a layer:

Create a file at postcss-plugins/postcss-layer-wrapper.js:

const postcss = require('postcss')
 
module.exports = () => ({
  postcssPlugin: 'postcss-layer-wrapper',
  Once(root, { result }) {
    // Get the file path from the result object
    const filePath = result.opts.from
 
    // Only proceed if it's from node_modules
    if (!filePath || !filePath.includes('node_modules')) {
      return
    }
 
    const layerRule = postcss.atRule({ name: 'layer', params: 'external' })
    const nodesToMove = []
 
    // Collect nodes that can be safely wrapped
    root.each((node) => {
      // Skip @import, @charset, and other non-layerable nodes
      if (node.type === 'atrule' && ['import', 'charset'].includes(node.name))
        return
      nodesToMove.push(node)
    })
 
    // Move collected nodes
    nodesToMove.forEach((node) => {
      node.remove()
      layerRule.append(node)
    })
 
    // Add layer only if it contains nodes
    if (layerRule.nodes && layerRule.nodes.length > 0) {
      root.prepend(layerRule)
    }
  },
})
 
module.exports.postcss = true

Configure PostCSS in your project:

Create or update postcss.config.js:

module.exports = {
  plugins: [
    // include default Next.js plugins
    'postcss-flexbugs-fixes',
    [
      'postcss-preset-env',
      {
        autoprefixer: {
          flexbox: 'no-2009',
        },
        stage: 3,
        features: {
          'custom-properties': false,
        },
      },
    ],
    // custom plugin
    './postcss-plugins/postcss-layer-wrapper.js',
    // cssnano should come last in production
    process.env.NODE_ENV === 'production' ? 'cssnano' : undefined,
  ].filter(Boolean),
}

Wrap your global styles in a layer:

In your globals.css:

@layer global, external;
 
@layer global {
  /* Your global styles here */
  .button {
    background-color: blue;
    color: white;
  }
}

Install required dependencies:

npm install -D postcss-flexbugs-fixes postcss-preset-env cssnano

This solution uses CSS layers to explicitly control the cascade order, ensuring that your styles are applied consistently regardless of the environment.

Solution 2: Disable CSS Chunking

A simpler but less optimal solution is to disable CSS chunking in your Next.js configuration:

// next.config.js
module.exports = {
  experimental: {
    cssChunking: false,
  },
}

This forces Next.js to bundle all CSS into a single file, which can help maintain a more consistent order. However, it comes at the cost of larger initial CSS loads and may not solve all instances of the issue.

Solution 3: Increase Specificity for Component Styles

You can also work around the issue by increasing the specificity of your component styles:

/* Instead of this */
.button {
  background-color: red;
}
 
/* Use this */
.component .button {
  background-color: red;
}
 
/* Or this */
.button[class] {
  background-color: red;
}

While this approach works, it's less ideal as it requires changing your CSS architecture and can lead to specificity wars.

For Next.js Project Maintainers: How to Make Your Projects More Resilient

If you're maintaining a Next.js project, consider these improvements:

Implement a CSS architecture that's less dependent on order:
- Use BEM or another naming methodology to reduce selector conflicts
- Avoid relying on the natural cascade for overrides
- Use more specific selectors for component styles

Add visual regression testing to catch styling issues between environments:

// Example with Cypress and Percy
describe('Visual Regression', () => {
  it('Button component renders correctly', () => {
    cy.visit('/your-page')
    cy.get('.button').should('be.visible')
    cy.percySnapshot('Button Component')
  })
})

Consider using CSS-in-JS solutions that are less affected by this issue, such as styled-components or emotion.

How to Identify If Your Project Is Affected

You might be affected by this issue if you're experiencing any of these symptoms:

Styles look different in production compared to development
Global styles unexpectedly override component styles in production
CSS specificity seems to work differently between environments
You're using the Next.js App Router with a mix of global and component styles

To test if your project is affected, compare the styling between:

Local development (next dev)
Local production build (next build && next start)
Deployed production environment

If you notice inconsistencies, particularly with global styles overriding component styles in production but not in development, you're likely experiencing this bug.

Conclusion: Ensuring Consistent Styling in Next.js Applications

The Next.js CSS resolution order bug highlights the challenges of modern frontend development across different environments. While we await an official fix, being aware of the issue and implementing the solutions outlined in this guide will help you maintain consistent styling in your Next.js applications.

Remember these key takeaways:

Use CSS layers to explicitly control style ordering
Consider disabling CSS chunking if appropriate for your project
Implement visual regression testing to catch styling inconsistencies early
Design your CSS architecture to be less dependent on cascade order

By following these best practices, you can avoid hours of frustrating debugging and ensure your Next.js projects look consistent across all environments.

Have you encountered this issue in your projects? What other Next.js styling quirks have you discovered? Share your experiences in the comments below!

Did you find this article helpful? Follow me for more React and Next.js development tips and solutions to common web development challenges.

Solving the Next.js CSS Resolution Order Bug: A Complete Guide for React Developers