CSS ordering from shared chunk not deterministic with multi entry points

[ferdaber]

Minimal reproduction repo (kind of): https://github.com/ferdaber/css-plugin-ordering-bug
Node: v9.11.1
OS: MacOS v10.12.6

With the latest version v0.4.1, in multiple-entry-points situations, I found that the CSS ordering is not deterministic. I set up a repo that "reproduces" the bug to the best of my ability (before getting stuck in Webpack internals).

The gist of it is that in cases where a chunk is shared between multiple chunk groups, it's not always the case that the first chunk group actually has the CSS modules that we want to sort on, which results in this line returning undefined for the module index:
https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/src/index.js#L393

Chunk groups:

• entry-a~vendor: has a.js and shared_modules/other.js
• entry-b~vendor: has b.js, shared_modules/red.css and shared_modules/blue.css

In my repo, I set it up so that anything in shared_modules is split out into a separate chunk, but have the entry points ordered such that the first chunk group contains no CSS modules (entry-a's dependency tree only contains JS files but touches the shared_modules chunk group). This leads to the sorting mechanism as mentioned above to return undefined for a CSS module's index.

The output in this repo still ended up having the correct ordering but I think it was because the chunk.modulesIterable set had the correct ordering at the time:

Output css/vendor.css:

html {
  background: blue;
}
html {
  background: red;
}

Expected css/vendor.css:

html {
  background: red;
}
html {
  background: blue;
}

To my understanding, chunk.modulesIterable is generated (or added) asynchronously so the ordering is not always guaranteed?

At this point I got stuck trying to get more information to submit to this issue, if a maintainer could offer me some guidance to what a better chunking strategy would be to work around this, or a fix for this, that would be super appreciated - thanks!

[alexander-akait]

/cc @sokra

[dtothefp]

@evilebottnawi I can report a similar issue from the v4.0.1 release. This is pretty much the exact same behavior I was seeing when upgrading to Webpack 4 and using the extract-text plugin webpack-contrib/extract-text-webpack-plugin#745

I have a single entrypoint and am using PostCSS Loader with CSS modules. In development without extraction everything works as expected, although in prod when using mini-css-extract I see a regression in order of some classes. Reverting to `0.4.01 fixes the issue.

This seems to be happening in combination with using the

• postcss-import module
• using composes: via CSS loader

ex. the following css most likely occurs in various files throughout the application resulting in class duplication and changes in order

@import 'config/common.css';
@import 'config/header.css';

.container {
  position: relative;
}

.cta-text {
  composes: heading-4 from 'helpers/typography.css';
}

This problem is in a large repo and I'm having problems replicating it in a minimal use case but when I do I will post a demo.

In the real life situation:

the order of css is wrong (typography__heading-1 should be the base style, and then overwritten with the Hero__heading)

Resulting from the following CSS when both global.css and Hero.css are extracted together into the same file:

// global.css
@import 'helpers/typography.css';

// Hero.css
.text-headline {
  composes: heading-1 from 'helpers/typography.css';
  color: var(--color-text);

  @media (--large-up) {
    width: 100%;
  }
}

//main.js
import './global.css';
import Hero from `./Hero'; // where Hero.js imports Hero.css as css-module

[boraturant]

This issue is same as #188

I have also posted a repo that shows the problem at https://github.com/boraturant/MiniCssExtractPlugin_CSSOrderProblem

[smrq]

Ran into this as well. I have another somewhat minimal repro but it is not pretty, as triggering an actual bug with this requires hitting a random case where Array.prototype.sort yields weird behavior given the existence of a stray undefined. Altering file paths, order of imports, etc. can trigger or fix the problem.

https://github.com/smrq/mini-css-extract-plugin-repro

Perhaps order modules by their position in the first chunk group, then any modules not existing in the first chunk group by their position in the second chunk group, etc.?

https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/src/index.js#L390

-    const [chunkGroup] = chunk.groupsIterable;
-    if (typeof chunkGroup.getModuleIndex2 === 'function') {
-      modules.sort((a, b) => chunkGroup.getModuleIndex2(a) - chunkGroup.getModuleIndex2(b));
-    } else {

+    if (typeof chunk.groupsIterable[0].getModuleIndex2 === 'function') {
+      let sortedModules = [];
+      chunk.groupsIterable.forEach(chunkGroup => {
+        sortedModules = sortedModules.concat(
+          modules.filter(m => chunkGroup.getModuleIndex2(m) != null)
+            .sort((a, b) => chunkGroup.getModuleIndex2(a) - chunkGroup.getModuleIndex2(b)));
+        modules = modules.filter(m => chunkGroup.getModuleIndex2(m) == null);
+      });
+      modules = sortedModules;
+    } else {

[cameronbraid]

I have a css ordering issue with multiple entry points broken for both 0.4.1 and 0.4.2

0.4.0 does the right thing

[cameronbraid]

I was thinking about this issue and I think what the user would expect is that the css extractor orders the styles the same way they are done when you run devserver.

So, if there is a common chunk that needs to be ordered differently for two other chunks then I should think that either there needs to be two common chunks output.

[smelukov]

The same issue.
Are there any changes? )

[smelukov]

If we use style-loader instead of mini-css-extract-plugin then the problem is gone (chunks ordered correctly), but style-loader is not what we need cause it can't extract text :(

[nmfzone]

Any update on this? 🤔

Mention maintainer: @sokra

[alexander-akait]

PR welcome