Inconsistent CSS resolution order

[GabenGar]

Link to the code that reproduces this issue

https://github.com/GabenGar/repros/blob/main/nextjs/css-out-of-order/README.md

To Reproduce

Reproduction steps are in the README.md

Current vs. Expected behavior

Current: Different CSS resolution order between development and production. Before I had weird client vs. render CSS issues, but it looks like they are fixed in 14.2, although they weren't super reproducible before either. Expected: Work basically like pages router.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10
  Available memory (MB): 7990
  Available CPU cores: 4
Binaries:
  Node: 20.9.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.2 // Latest available version is detected (14.2.2).
  eslint-config-next: 14.2.2
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.5
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed)

Additional context

No response

[payamtrack]

Hi Team,

We have a similar issue. Our next.js (v14.2.10) project is using SCSS modules (like page.modules.scss) as well as a globas.css file imported in the root layout.

Our application appears significantly different in production compared to the development server, due to inconsistencies in the order of CSS rules.

This discrepancy is a deal breaker for us, as it makes it unreliable to go live.

I appreciate any suggestions or updates on resolving this issue.

Thanks

[piratetaco]

I have isolated at least my issue to this commit released in 14.2.0. If I revert this, css emits in the correct order from a library with or without sideEffects: false set. Looking into why.

I have isolated library css improper order to the changes in this file.

For CSS files, I don't believe it is a good practice to restrict to only sideEffects: true, like is done in these lines. That forces library authors to sideEffect the entirety of their library including the JS. I think regardless of sideEffects true, false, or set as an array, behavior should always be roughly the same by letting the css compilers handle it, and sideEffects: true should be removed from likely all of these stipulations in this file. Likely responsible for many other existing css issues.