4.0.0-beta.0 adding a loader changes the order of generated CSS

[rightaway]

I'm using 4.0.0-beta.0. Without postcss-loader added below, I get the expected behavior, where the extracted css from vue-loader is appended to the end of the final css file. But adding 'postcss-loader' puts the extracted css to the beginning of the final css file which isn't correct.

    rules: [
      {
        test: /\.vue$/,
        loader: 'vue-loader',
        options: {
          extractCSS: true,
        },
      },
      {
        test: /\.css$/,
        use: ExtractTextPlugin.extract({
          use: [
            {
              loader: 'css-loader',
              options: { importLoaders: 1 },
            },
            'postcss-loader',
          ],
        }),
      },
    ],

[garygreen]

Possibly related to: #737 #710

[dtothefp]

I'm having a similar issue when upgrading to Webpack 4 and extract text beta-0. I'm using PostCSS Loader with CSS modules. In development without extract text everything works as expected, although in prod when using extract text I see a duplication of the same compiled CSS module classes in the bundle and a regression in order of some classes.

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.

[garygreen]

@dtothefp have you tried the Mini Css Extract Plugin ?

[dtothefp]

@garygreen yes I tried it after reading your response in other issues. Couldn't get it to work with PostCSS loader 🤷‍♂️

[dtothefp]

@garygreen I was wrong...I did get the mini-css / loader plugin to work and CSS classes are NOT duplicated and are in the correct order 😄. Unfortunately, this is in a large app that is using require.ensure syntax to chunk JS. With Webpack 2 and extract-text-plugin this was resulting in one large CSS bundle, whereas with mini-css this results in CSS chunks. This is great moving forward but unfortunately we have some animations, etc that rely on the CSS being loaded all at once. I'm wondering if there is any option in mini-css to disable chunking CSS while we work to address this problem?

[garygreen]

@dtothefp sounds like you need to configure the splitChunks optimization. I've never used the ensure syntax, I believe that would count as an async chunk? I'd imagine you need to create some splitChunk groups and with the help of the test chunks and enforce options you should be able to get it to chunk as desired. Can be a bit fiddly though, good luck!
https://gist.github.com/sokra/1522d586b8e5c0f5072d7565c2bee693

[dtothefp]

@garygreen looks definitely interesting but hard to understand the config. I tried something like below but it had no effect. I feel like I'm not figuring out how to test for the CSS chunks

    optimization: {
      splitChunks: {
        cacheGroups: {
          commons: {
            name: 'commons',
            test: /\.css$/,
            chunks: 'all',
            minChunks: 2,
            enforce: true
          }
        }
      }
    },

[michael-ciniawsky]

TL;DR Use mini-css-extract-plugin instead :)

The webpack >= v4.0.0 'support' for extract-text-webpack-plugin was moved to mini-css-extract-plugin as more lightweight approach for webpack >= v4.0.0 and ETWP entered maintenance mode. We are sorry for the inconvenience here, but ETWP reached a point where maintaining it become too much of a burden and it's not the first time upgrading a major webpack version was complicated and cumbersome due to issues with ETWP. The mid-term plan is integrate CSS support directly into webpack to avoid this kind of issue in the future

[jtomaszewski]

Why has this issue been closed? This is still not resolved.

If we plan not to support webpack 4 at all, why don't we add a NOTE to README, that indicates that people should use mini-css-extract-plugin instead ? Like in #759 .

Right now there's a ETWP 4.0 beta which confuses a lot of users, that this plugin is suited for webpack 4, while unfortunately, atm it's not. Switching to mini-css-extract-plugin takes a second, so it's not a big trouble while upgrading to webpack 4.