mini-css-extract-plugin throws "Conflicting order" errors during build

[dviry]

(react-scripts 2.0.4)
Same as in this issue I am getting a lot of errors from the mini-css-extract-plugin when doing a CI build - which fails since no warnings are allowed.
Since CRA does not allow customizing the WebPack plugin config, I cannot use the warningsFilters and the question about CRA also already popped up.

I am not sure what the CRA team can do about this - but maybe just keep an eye on it (or have it documented as a Known Issue) until WebPack somehow solves it.

PS: for now I am running "set CI=&&react-scripts build" to disable the CI build warnings limit.

[andriijas]

Are you using 3rd party styling library like antd, bootstrap or anything else?

Like mentioned in the related issue webpack-contrib/mini-css-extract-plugin#250 (comment) the problem should not just be ignored by disabling and hiding the warnings but addressing the source cause instead, its not healthy to have fragile and inconsistent builds.

[holloway]

@dviry fyi I solved this by importing all CSS from a single file, and for code-split styles I'll migrate to a CSS-in-JS approach (probably Glamor styled-components).

[Timer]

Yeah, this is a very valid problem. A light change in your code could alter the cascading effects of your CSS, so this is warranted. Maybe some docs on how to fix it would be nice.

[ryancogswell]

@Timer This seems like more than a documentation problem. I'm working on un-ejecting, but couldn't before 2.0 because of using Sass and CSS modules. Now with 2.0, I'm getting a bunch of these warnings, but we are using CSS modules for everything so there's no chance of the order actually being important (we aren't using any global styles -- just CSS classes).

[ryancogswell]

In our case, I've worked around this by importing within index.js the components that directly use the CSS files that the warnings were complaining about. This resolves the order ambiguity and in my case, the components are shared pieces that are fine to be in my "main" chunk.

[bogdan-calapod]

I also have this problem, and the error message is utterly useless and frustrating. On a large project it isn't feasible to randomly start requiring the devs to update their CSS based on arbitrary rules.

I'm using this with SCSS, and I'm even more confused on what it wants from me. The linked issue doesn't help much either.

[stereobooster]

chunk 0 [mini-css-extract-plugin]
Conflicting order between:
 * css ./node_modules/css-loader??ref--6-oneOf-4-1!./node_modules/postcss-loader/src??postcss!./src/form.module.css
 * css ./node_modules/css-loader??ref--6-oneOf-4-1!./node_modules/postcss-loader/src??postcss!./src/components/Footer/Footer.module.css

We use CSS Modules. The problem is in our code, but it is hard to understand what exactly is the issue. It complains about order of css imports in asset graph, but which exactly files?

Related webpack-contrib/mini-css-extract-plugin#250

[theZieger]

I also had an issue with the mini-css-extract-plugin warning about a confliction order. Good thing was I'm in complete control of the component library we are using. But finding the correct spot where the problem occurs was really tough. I'm not an expert regarding webpack and neither the mini-css-extract-plugin or any of this. That's why I use CRA in the first place - I don't want to deal in detail with webpack and it's plugin ecosystem.

Nonetheless I was able to fix my component library. I'll just leave this here, so it may be some help to others hopefully.

Before the change:

BaseButton.js

import React from 'react';
import classnames from '../../../classnames';

import '../../../global/Global.css';
import './BaseButton.css';

export default function BaseButton({ children, type, className, ...other }) {
  return (
    <button
      className={classnames('base-button', className)}
      type={type}
      {...other}
    >
      {children}
    </button>
  );
}
BaseButton.defaultProps = {
  /** the type of the button */
  type: 'button'
};

IconButton.js

import React from 'react';

import BaseButton from '../BaseButton/BaseButton';
import classnames from '../../../classnames';

import '../../../global/Global.css';
import './IconButton.css';

export default function IconButton({ className, ...props }) {
  return (
    <BaseButton className={classnames('icon-button', className)} {...props} />
  );
}

When I used the components in that way, the CSS generated on build was not in the order I suspected it to be. When looking at the code of IconButton.js I would assume that the build process would put BaseButton.css before IconButton.css. But in fact it was in the wrong order ... this led to wrongly applied CSS rules (because cascading). And yeah maybe I should move on to use CSS Modules.

Anyway her my solution - even though I can't explain why this works now:

BaseButton.js

import React from 'react';
import classnames from '../../../classnames';

export default function BaseButton({ children, type, className, ...other }) {
  return (
    <button
      className={classnames('base-button', className)}
      type={type}
      {...other}
    >
      {children}
    </button>
  );
}
BaseButton.defaultProps = {
  /** the type of the button */
  type: 'button'
};

IconButton.js

import React from 'react';

import BaseButton from '../BaseButton/BaseButton';
import classnames from '../../../classnames';

import '../../../global/Global.css';
import '../BaseButton/BaseButton.css';
import './IconButton.css';

export default function IconButton({ className, ...props }) {
  return (
    <BaseButton className={classnames('icon-button', className)} {...props} />
  );
}

Maybe one of you can explain this to me or maybe this even helps you finding a similiar solution on your projects. Just wanted to share ... and this is the first issue I found regarding CRA and mini-css-extract-plugin.

[gonzofish]

@theZieger what's in Global.css?

[theZieger]

@gonzofish some normalize styles but mostly custom properties (CSS variables)

[gonzofish]

I'm wondering if importing them over and over is causing a headache? I can't get mine to stop spitting out errors either

[theZieger]

In my case it doesn't seem to be a problem importing Global.css over and over again in multiple components.
And btw I don't get any warnings anymore after I applied the above changes I posted... But still discover smaller issues regarding the final output order.

[gonzofish]

In my case, I had to reorder my imports, but it's not clear why:

I went from:

import AudienceComposition from '../../../shared/components/AudienceComposition/AudienceComposition';
import MetricPicker from '../../../shared/components/Bb8MetricPicker/Bb8MetricPicker';
import BulmaMessage from '../../../shared/components/BulmaMessage/BulmaMessage';
import EntityCard from '../../../shared/containers/Bb8EntityCard/Bb8EntityCard';
import EntitySearch from '../../../shared/containers/EntitySearch/EntitySearch';

to

import MetricPicker from '../../../shared/components/Bb8MetricPicker/Bb8MetricPicker';
import BulmaMessage from '../../../shared/components/BulmaMessage/BulmaMessage';
import EntityCard from '../../../shared/containers/Bb8EntityCard/Bb8EntityCard';
import EntitySearch from '../../../shared/containers/EntitySearch/EntitySearch';
import AudienceComposition from '../../../shared/components/AudienceComposition/AudienceComposition';

Even as I look at the imports of SASS files from each of those files (and anything they import), I can't figure out what was causing problems. Because a SASS file that was used by a component AudienceComposition imported was causing conflicts with all of the other SASS files from MetricPicker, BulmaMEssage, EntityCard, and EntitySearch...even when I had removed all code from the SASS file...

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[rfearing]

I'm still having this issue too

[ryanashcraft]

This was one of the few reasons I needed to fork react-scripts. We use CSS modules so ordering doesn't really matter for us. And there's no clear way to address the warnings as the modules in conflict are in completely separate, very-distant parts of the parsed module tree.

[pelotom]

For users of CSS Modules it seems like ignoring the warnings (as described here) is a safe workaround.

[ryanashcraft]

@pelotom Indeed but it requires ejecting or forking.

[mAiNiNfEcTiOn]

Well we're also using CSS Modules (with dynamic imports) and also had this issue... So we decided to downgrade.

While downgrading got rid of the warnings, it did not get rid of the consequence of having this reported issue. We basically ran into cases where based on your starting page it would determine how the styles would be affected.

We kind of solved it by adding this to webpack's config:

  optimization: {
    /* ... */
    splitChunks: {
      chunks: 'all',
      name: false,
      cacheGroups: {
        styles: {
          name: false,
          test: /\.css$/,
          chunks: 'all',
          enforce: true,
        }
      },
    },
    runtimeChunk: true, // This line is just for you to know where I added the lines above.
  },

which resulted on certain common styles being moved to one chunk.

Now, is it the right way, or a way to solve issues? Probably not.... Just putting it out as either you guys will tell me "NO DON'T DO IT" or maybe it solves your problem.

[valscion]

Please note that my comment linked by @pelotom above does not reflect the opinions of webpack or mini-css-extract-plugin team. Don't let the "Member" highlight give me authority on that specific issue. I merely have that highlight as I'm maintaining a different webpack-contrib package, webpack-bundle-analyzer.

[feonit]

I tried to find the import place that invoke the trouble (by method exception) and after I replaced some strings annoyance is out, but this behavior still looks like some weird for me

[patientplatypus]

Yeah, I'm having this. Why?

[joa]

It seems like there are three solutions to this issue:

1. Eject and use custom warning filters
2. Sort all imports in all files of your code base alphabetically
3. Use CI=false which means you still get the warning but your pipelines won't freak out

It would be great if one could chose to suppress this warning OR if CI=true yarn build would simply have a 0-exit-code albeit the warnings -- without having to eject.

When using CSS modules one is probably not interested in any cascading overrides. At least it would go against the idea of using modules in the first place.

[NicoleJaneway]

@samueldaraho in webpack.config.js

[ozkary]

Adding some thoughts here. I have seen this problem take place when there is a circular reference in imports. For example, FileA has imports from FileB and FileB has imports from FileA. This triggers that error downstream when those files are imported by UI components.

[puopg]

Just a thought, but if we are using CSS Modules, as stated above, does it really matter about the order? Assuming things are scoped to components, no wild uses of globals, I feel like it should be totally valid to just set ignoreOrder: true.

Counter examples welcomed, but just in case im misunderstanding something, I feel like the conflicting order error is more for projects that don't have that luxury that CSS modules or other similar approaches provide.

[ozkary]

This error happens frequently when the sequence of imports is not the same in all containers/modules, so the code split finds an ambiguous pattern and raises the warning conflicts.

As a simple example, take a look at these two modules:

// Module 1

Import toolbar
Import taskbar
Import notifications

// Module 2

Import CompositeComponent  /*CONFLICT ABOUT TO SHOW*/
Import toolbar
Import taskbar

// CompositeComponent

Import notifications

If you take a look at this case, module 2 imports a new composite component at the top, which imports the notification component. This essentially brings the notification import ahead of the toolbar and taskbar, which is not what module 1 is doing.

In this case, the conflict will be with notification vs toolbar and taskbar as the warning message probably indicates. To fix this simple example, move the CompositeComponent to the end of the imports, which essentially brings the notification import to the end

// Module 2

Import toolbar
Import taskbar
Import CompositeComponent

[h-attila]

HI! I had the same problem, and eslint-plugin-import solved it. It orders the import lines in alphabetic order, so it solves the order conflict.
More info here:
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md

[LordMendes]

In case you use the solution proposed by @myxious make sure to only override the MiniCssExtractPlugin configuration in production to avoid the following error: UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'options' of undefined

const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  webpack: {
    configure: (webpackConfig, { env }) => {
      if (env === 'production') {
        const instanceOfMiniCssExtractPlugin = webpackConfig.plugins.find(
          plugin => plugin instanceof MiniCssExtractPlugin
        );

        instanceOfMiniCssExtractPlugin.options.ignoreOrder = true;
      }

      return webpackConfig;
    },
  },
};

or just do something like:

if(env == 'development') return webpackConfig

[marcosdiasdev]

Remove cruft - You can clear away the timestamps and error text pretty quickly and see that there are pairs of files which have been imported in different orders at some point during the build process.
Graph.module.css
Spinner.module.css
GraphWrapper.module.css
Spinner.module.css
Spinner.module.css
GraphOptionsBar.module.css

As @rob-gordon mentioned, the point is to pay attention at the modules listed in the output message. Fortunately, in my case, there were only two modules conflicting in my project. It turned out that one of them wasn't even being used so I just removed the import and voilà!

[krutoo]

I found out by experiments that dynamic imports cause this problem in my case.

in my project there is a dependency - a component library that exports react components that import SCSS modules

in my project mini css extract plugin is configured in such a way to collect all styles in one file according to the guide

entry point of project contains several dynamic imports of moodules that has css modules imports

is it possible to somehow configure this plugin to automatically collect styles from files for each dynamic import separately?

[steveswork]

Have you tried the @webkrafters/ordercss on NPM? It may help you clear up this problem.

[scriptify]

For everyone using NX and stumbling across this problem, I solved it by setting the ignoreOrder property to true in my custom webpack config.
Sorting all imports with prettier still gave some warnings (very large codebase though).

/**
 *
 * @returns @type {import('webpack').Configuration}
 */
module.exports = composePlugins(
  withNx(),
  withReact({
    svgr: false,
  }),
  (config, { context }) => {
    const miniCssExtractPlugin = config.plugins.find(
      (plugin) => plugin.constructor.name === 'MiniCssExtractPlugin'
    );

    if (miniCssExtractPlugin) {
      miniCssExtractPlugin.options.ignoreOrder = true;
    }

    return config;
  }
);

// Functional purists may overwrite the plugins array by using `map` 😉

[krutoo]

For everyone using NX and stumbling across this problem, I solved it by setting the ignoreOrder property to true in my custom webpack config. Sorting all imports with prettier still gave some warnings (very large codebase though).

/**
 *
 * @returns @type {import('webpack').Configuration}
 */
module.exports = composePlugins(
  withNx(),
  withReact({
    svgr: false,
  }),
  (config, { context }) => {
    const miniCssExtractPlugin = config.plugins.find(
      (plugin) => plugin.constructor.name === 'MiniCssExtractPlugin'
    );

    if (miniCssExtractPlugin) {
      miniCssExtractPlugin.options.ignoreOrder = true;
    }

    return config;
  }
);

// Functional purists may overwrite the plugins array by using `map` 😉

it's not really a solution =)

#5372 (comment)

[scriptify]

For everyone using NX and stumbling across this problem, I solved it by setting the ignoreOrder property to true in my custom webpack config. Sorting all imports with prettier still gave some warnings (very large codebase though).

/**
 *
 * @returns @type {import('webpack').Configuration}
 */
module.exports = composePlugins(
  withNx(),
  withReact({
    svgr: false,
  }),
  (config, { context }) => {
    const miniCssExtractPlugin = config.plugins.find(
      (plugin) => plugin.constructor.name === 'MiniCssExtractPlugin'
    );

    if (miniCssExtractPlugin) {
      miniCssExtractPlugin.options.ignoreOrder = true;
    }

    return config;
  }
);

// Functional purists may overwrite the plugins array by using `map` 😉

it's not really a solution =)

#5372 (comment)

It depends. If you use CSS Modules without :global and/or make use of BEM for the rest of your CSS, it is a solution.
If you sort all your imports, and the error still persists, it is probably caused by a library you are using. You can now of course go to that library and open a PR, and if you're lucky it might even get merged. For the rest of us, who use CSS responsibly, this warning, if it doesn't cause any test to fail, can be ignored.

Also, have a look at this awesome write-up on SO

[nusjeff]

In case you use the solution proposed by @myxious make sure to only override the MiniCssExtractPlugin configuration in production to avoid the following error: UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'options' of undefined

const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  webpack: {
    configure: (webpackConfig, { env }) => {
      if (env === 'production') {
        const instanceOfMiniCssExtractPlugin = webpackConfig.plugins.find(
          plugin => plugin instanceof MiniCssExtractPlugin
        );

        instanceOfMiniCssExtractPlugin.options.ignoreOrder = true;
      }

      return webpackConfig;
    },
  },
};

or just do something like:

if(env == 'development') return webpackConfig

I tried doing this solution and the error was solved completely!

[Ankit8969]

I also got this issues, in my 5-6 files,
So, what i did
I create a global scss file and put all the css code in that file and delete the other,
this is how this issues got resolved

[fregante]

Here's my understand and solution to the issue. It's not very straightforward because it requires you to understand how the imports appear in the code, in the entire import tree.

What's causing them?

Context:

• webpack attempts to create CSS files shared among entries
• order matters in CSS, e.g.: a{color: red; color: blue}

If a build entry imports 2.css; 1.css and the other 1.css; 2.css, the generated file can only follow one of the orders; That's what the error means.

What do they cause?

If the styles actually overlapped each other, the style imported later (in the source code) wouldn't be applied because it still appeared earlier in the output CSS file.

Fix

Ensure that the order is always the same. Example:

Conflicting order. Following module has been added:
 * css /node_modules/react-image-crop/src/ReactCrop.scss
despite it was not able to fulfill desired ordering with these modules:
 * css /node_modules/@fortawesome/fontawesome-svg-core/styles.css
   - couldn't fulfill desired order of chunk group(s) isolated/EphemeralFormContent
   - while fulfilling desired order of chunk group(s) isolated/CustomFormComponent

You have to figure out which packages lead to ReactCrop.scss and fontawesome-svg-core.css. In this case, I opened the two entry points for the mentioned chunks

1. open EphemeralFormContent.ts and CustomFormComponent.ts
2. among the imports, locate the one that eventually leads to ReactCrop.scss
3. in this case ImageCropWidget, move it to the top of the file, in both EphemeralFormContent.ts and CustomFormComponent.ts
4. do the same for the fontawesome-svg-core importer, if the error hasn't been fixed already