Craco start and craco build causing different css ordering

[ndbroadbent]

From: https://github.com/sharegate/craco/issues/57

We recently moved over to craco from react-app-rewired, in conjunction with ant-design. However the css is applied differently when running locally compared to running the completed build. Below is the contents of the craco.config.js file. test const CracoAntDesignPlugin = require('craco-antd'); const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer'); const WebpackBar = require('webpackbar'); module.exports = { plugins: [{ plugin: CracoAntDesignPlugin }], webpack: { plugins: [ new WebpackBar({ profile: true }), ], }, };

Is this the correct way to ensure that the ant-d styles will be applied last, or have I missed something?

[ndbroadbent]

@PatchOnKnee This config looks correct to me, but this is probably a bug.

There are a few differences between the dev and prod config, but I'm not sure why those would change the order of the CSS.

Is this the correct way to ensure that the ant-d styles will be applied last

I think it would make sense to apply the ant-d CSS first, so that you can override it with your own custom CSS? Sorry I'm not sure if I fully understand the issue.

[icecoldmax]

I'm getting a similar issue I think - the customizeTheme options are being applied differently in build than with start.

  plugins: [
    {
      plugin: CracoAntDesignPlugin,
      options: {
        customizeTheme: {
          "@primary-color": "#337AB7",
          "@layout-header-background": "#252D3B",
        }
      }
    }
  ]

The @primary-color is applied correctly when running with craco start, but with craco build it goes back to default ant-d colours.

Looking in the Chrome inspector at an AntD button of type primary:

craco start - primary colour override in <style> tags:

craco build - primary colour override in mixin.less and deactivated:

... and the default colour is being applied in <style> tags like with craco start.

[kmcaloon]

@ndbroadbent I can confirm that this is definitely due to the stylesheet chunks being injected in the wrong order during build. I'm assuming this has something to do with the less loader, but can't really seem to spot the issue

[kmcaloon]

Actually this is more likely related to miniCssExtractt. I also don't think the plugin options are properly modifying the loader rules for build. For example, when I experiment and modify the chunkFilename option for miniCssExtractPLuginOptions, it has no affect on the build output.

[chetanpan]

Hi,

I am facing same!

After building, I have to change order of links to stylesheets manually in index.html to make things work correctly...

Regards

[ndbroadbent]

Hi everyone, I've started looking into this but am having some problems reproducing the issue.

I've created a test-app and a puppeteer test that builds the production assets, serves them, opens up the page in Chrome, and checks that the CSS overrides are working properly. It also clicks a button to make sure that a counter state increments.

Could someone please take a look at this puppeteer test and let me know how I can reproduce this CSS ordering issue? Thanks!

(I'm also working on #10, to get the jest tests working for App.test.tsx.)

[JacksonBates]

I'm just leaving my notes here for potential weary travelers!

I encountered a related issue to this CSS ordering warning coming from MiniCssExtractPlugin. The warnings were making my CI fail, but the app worked fine.

I decided to suppress the warnings, as outlined here: https://github.com/webpack-contrib/mini-css-extract-plugin/blob/v0.8.0/README.md#remove-order-warnings

However, MiniCssExtractPlugin already exists in the original webpack config, so I had to replace it with a new one, with ignoreOrder set to true. My final craco.config.js looks like this:

const CracoAntDesignPlugin = require("craco-antd");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");

module.exports = {
  webpack: {
    configure: (webpackConfig, { env, paths }) => {
      webpackConfig = {
        ...webpackConfig,
        plugins: [
          ...webpackConfig.plugins.filter((element) => {
            if (element.options) {
              return !element.options.hasOwnProperty("ignoreOrder");
            }
            return true;
          }),
          new MiniCssExtractPlugin({
            filename: "static/css/[name].[contenthash:8].css",
            moduleFilename: this.moduleFilename,
            ignoreOrder: true,
            chunkFilename: "static/css/[name].[contenthash:8].chunk.css",
          }),
        ],
      };
      return webpackConfig;
    },
  },
  plugins: [{ plugin: CracoAntDesignPlugin }],
};

I'd love a better way of targeting the original MiniCss plugin to remove it than the naive filter I used - but this was a 1am decision after many hours trying to resolve the issue - happy to hear a better way.

Hope this helps someone!

[cpconcertage]

I'm just leaving my notes here for potential weary travelers!

I encountered a related issue to this CSS ordering warning coming from MiniCssExtractPlugin. The warnings were making my CI fail, but the app worked fine.

I decided to suppress the warnings, as outlined here: https://github.com/webpack-contrib/mini-css-extract-plugin/blob/v0.8.0/README.md#remove-order-warnings

However, MiniCssExtractPlugin already exists in the original webpack config, so I had to replace it with a new one, with ignoreOrder set to true. My final craco.config.js looks like this:

const CracoAntDesignPlugin = require("craco-antd");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");

module.exports = {
  webpack: {
    configure: (webpackConfig, { env, paths }) => {
      webpackConfig = {
        ...webpackConfig,
        plugins: [
          ...webpackConfig.plugins.filter((element) => {
            if (element.options) {
              return !element.options.hasOwnProperty("ignoreOrder");
            }
            return true;
          }),
          new MiniCssExtractPlugin({
            filename: "static/css/[name].[contenthash:8].css",
            moduleFilename: this.moduleFilename,
            ignoreOrder: true,
            chunkFilename: "static/css/[name].[contenthash:8].chunk.css",
          }),
        ],
      };
      return webpackConfig;
    },
  },
  plugins: [{ plugin: CracoAntDesignPlugin }],
};

I'd love a better way of targeting the original MiniCss plugin to remove it than the naive filter I used - but this was a 1am decision after many hours trying to resolve the issue - happy to hear a better way.

Hope this helps someone!

Very helpful. I didn't even have time to become a weary traveler!

[olihou]

This is a hope that is bug will be resolved ?