mini-css-extract-plugin WARNING in chunk chunkName [mini-css-extract-plugin] Conflicting order between:

It can easily become an annoying bug! I can see it being reported in every framework — e.g. in issue #5372 in create-react-app, issue #250 in the mini-css-extract-plugin itself, etc.

I spent 6 hours debugging it (including putting console.log in the source code of mini-css-extract-plugin where it omits the Warning) and here are my findings.

What is this plugin?

The mini-css-extract-plugin of webpack is a CSS-bundler. It is there to gather CSS pieces and put them into .css chunks for you. Just like what the whole Webpack build is doing for .js files.

Why is it happening to me?

You are running into it because all of these conditions apply to you:

  1. You have Vue SFC or CSS-in-JS, that results in your CSS content being in different files (which are called modules).
  2. Your webpack configurations are set to do some sort of code-splitting optimizations, (e.g. via split-chunks-plugin) which puts your modules into chunks for lazy-loading in client-side (e.g. 1000 files, into 10 chunks, that are only downloaded by the user when the user needs them.) So, this plugin goes over how webpack has bundled your modules and tries to create its own CSS bundles out of them.
  3. There is an “Order Conflict” in your imports!

What is “Order Conflict” now?

It’s “order” + “conflict.” Let’s review them.

Part 1) Order

This plugin is trying to run a topological sorting algorithm (this part of the source code) to find out in which order it should put the CSS rules in its output bundles so that it doesn’t cause any problem.

The problem is, unlike JavaScript that you clearly export your objects from a file/module (in no order, as they are named), in CSS it will just get appended (like an array of strings) and so the order of the imports can actually matter!

Let’s say you have two modules:

// module a.js
<div>hi, I am A!</div>
// ... in CSS section of the same file:
div { color: red; }
// module b.js
<div>hi, I am B!</div>
// ... in CSS section of the same file:
div { color: blue; }

And then you have a page that includes both of them them.

// page S (for Straight)
import a from "a.js"
import b from "b.js"

So far, so good! The CSS output can be

div { color: red; }
div { color: blue; }

which means all the <div>s should have blue font color.

However, if instead of that page S, we had a page had was importing them in reverse order, it would be:

// page R (for Reverse)
import b from "b.js"
import a from "a.js"

and the output would be equal to

div { color: blue; }
div { color: red; }

which means all the <div>s should have red font color.

This is why the order of imports matters.

Part 2) Conflict

Now, what should be the output CSS if you have both page S and page R?

Note that, unlike this silly example of applying a wild rule on all <div> elements, you might actually have some sort of scoped CSS or a CSS naming convention like BEM in place that would prevent such thing to become an issue. But, this plugin doesn’t go over actually parsing and understanding the content of the CSS. It just complains that “Hey dude! I don’t know whether a should come before b, or b should come before a!


You basically have two solutions, just like any other problem! Either solve it or kill the problem it.

Solution 1: Fix it

The error message is very hard to read and sometimes it doesn’t even output the proper details of modules. (for me it’s like , , , , , , as for some reason my ChunkGroups don’t have a .name property; so zero information.) And it can be extremely messy if you have more than ~20 files.

Anyways, if you have got time this approach is the best you can try.


  • You can also import PageS in PageR (or the other way around, whatever) to explicitly tell the plugin to pick this order and stop nagging! It might be easier than going over all the places that include one or another and move the lines up and down.
  • IMPORTANT NOTE 2: The Order Conflict is NOT NECESSARILY IN THE SAME FILE. It can be anywhere among the ancestors of the two or more files! So, can be a huge pain to find out.
  • IMPORTANT NOTE 3: IT’S NOT GOING TO BE FUTURE-PROOF! So, even if you move a few import lines up and down, tomorrow it might happen to another developer in your team.

So, TL;DR, if you found yourself spending more than two hours on this, try solution #2 below.

Solution 2: Kill it

If it’s not actually causing a problem in production and your final output, you can suppress this error via passing an ignoreOrder flag to the options object of the plugin in your Webpack config.


  • If you are using a third-party build-wrapper on top of WebPack (like Quasar’s that I am using), you can use webpack chain modify arguments technique to feed this flag into the existing configuration.

It’s a good last resort! Good luck. 🙂

Leave a Comment