There's also #19012, but not much activity there anymore :(

CodSpeed Performance Report

Merging #19686 will degrade performances by 95.45%

_{Comparing fix/css_order (a99df5a) with main (ad1e3b4)}

Summary

⚡ 2 improvements
❌ 5 regressions
✅ 126 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Hi @ahabhgk, may I ask if that Rspack issue has been resolved? I'd appreciate it if you could take a look at this code as well. cc @alexander-akait @hai-x @jantimon

I chose to fix the dependency order directly at the point where module updates are triggered

I believe this is the key to success 👍 - My first idea was to solve the order only inside lib/optimize/SideEffectsFlagPlugin.js. However that failed for several reasons and that's why I believe your approach is better.

In my solution the following example caused a lot of headaches:

import {Foo} from "./foo-barrel";
import {Bar} from "./bar-barrel";

console.log(Bar);
console.log(Foo);

and

import {Foo} from "./barrel";
import {Bar} from "./barrel";

console.log(Bar);
console.log(Foo);

The problem here is that Bar is used before Foo and therefore the css of Bar would be loaded first although Foo was imported first.

Could you please double check that this not a problem in your solution anymore?

Hi @jantimon, big thanks for your earlier work. I’ve confirmed that the case you mentioned shouldn’t be an issue. The core of my fix is to sort HarmonyImportSpecifierDependency by import order, so downstream logic like module graph traversal behaves as expected.

In webpack, HarmonyImportSideEffectDependency keeps the original import order, but others like HarmonyImportSpecifierDependency are sorted by usage. This mismatch can cause ordering issues, once tree-shaking removes the HarmonyImportSideEffectDependency, loading CSS solely via HarmonyImportSpecifierDependency causes it to follow usage order instead of import order.

To fix this, I propose sorting HarmonyImportSpecifierDependency by import order as well, aligning with how native JS engines handle modules without bundlers.

No, Rspack haven't resolve this, actually most css order inconsistent problem we are facing is caused by splitChunks, we are working on that before and introduced a experimental plugin which is inspired by next.js, to at least let users can resolve it by their own. And since not many libraries will publish CSS Modules directly so we put this on a low priority.

The code looks good to me, I would probably write it in a similar way if let me work on it 😃