chunks option

[joscha]

We are migrating from a huge legacy codebase. Currently we have a static build for CSS, which basically takes a list of CSS files, concatenates them and minifies them.

We created entries for each of these groups, which look like this:

// ...
'bla/myCSSblobA': ['a/foo.css','b/xyz.css', 'c/another.css'],
'bla/myCSSblobB': ['a/foo2.css','b/xyz2.css', 'c/another2.css'],
// ...

and use the ExtractTextPlugin to generate a bla/myCSSblobA.css output, etc.
Unfortunately the ExtractTextPlugin extracts CSS from all our entry chunks, but we only need this for our legacy code. For the new code, we want to use the inline CSS. If we provided a chunks option (same functionality as for the CommonsChunkPlugin) which allowed to control from which chunks to extract and from which chunks not, would you be willing to merge it?

cc @timse @p0wl

[sokra]

For technical reasons this is not possible. A module could be in multiple chunks and the ETP extracts on per module basis.

But you can decide on per module basis which css is extract and which not:

i. e.

module.loaders: [
  [
    { test: /\.css/, include: path.resolve(__dirname, "a"),
      loader: ExtractTextPlugin.extract("style-loader", "css-loader") },
    { test: /\.css/,
      loader: "style-loader!css-loader" }
  ]
]

CSS in ./a is extracted everything else is extract.

Note the inner array for exclusive matching.

[joscha]

Thanks for the superfast response.
I see, we used a workaround now, which looks as following:

From the dependency/group information we create a file, that is a CSS file, which contains all the files the group consists of, e.g.:

legacy/bla/myCSSblobA.css:

@import "a/foo.css";
@import "b/xyz.css";
@import "c/another.css";

We then use a matcher on legacy for the text extraction plugin, e.g.

{
    include: legacyFolder,
    loader: ExtractTextPlugin.extract("style-loader", "css-loader")
}

Everything seems to work perfectly, we get one CSS file per legacy CSS "group", however the following error shows up:

ERROR in ./legacy/bla/myCSSblobA.css
Order in extracted chunk undefined

ERROR in ./legacy/bla/myCSSblobA.css
Order in extracted chunk undefined

(please note it appears twice for each file).
I dug around in the code of the text extraction plugin and the according issues/PRs but I couldn't find an explanation of why this might happen. Any hints?

[p0wl]

more findings to @joscha's information:

we found the problem, the error occurs because the modules are loaded in a different order in different entry points:

entry1.css:

• @import /s/css/buttons.css
• @import /s/bower_components/jquery-ui/themes/base/core.css

entry2.css

• @import /s/bower_components/jquery-ui/themes/base/core.css
• @import /s/css/buttons.css

the extract text plugin should not care about different loading orders for different entry points, right?

[sokra]

the extract text plugin should not care about different loading orders for different entry points, right?

Theoretically it should be irrelevant as each entry point results in a separate css file.

For technical reasons this emits an error as the ETP tries to find a global order of all CSS.

But you better reorder the CSS imports because you propably don't want a different order for each entry point. (This could result in different applied CSS for each entry point).

[joscha]

@sokra we agree that the order should be consistent, but I disagree that the text-extraction should fail if that is the case. Our group files are code that grew over a timeframe of 5 to 7 years and the ordering is inconsistent because entry points have nothing to do with each other and different developers work(ed) on different entry points. Ideally I'd propose to degrade the error to a warning, but that is a breaking change, so we opened #81.

[NogsMPLS]

Apparently this might somehow also effect CSS Modules?

I was getting the Order in extracted chunk undefined error with a css file that had this:

.tooltip {
  composes: absolute block p1 mt1 mb1 top-100 left-50 from '../styles/layout.css';
  composes: white bg-gray from '../styles/colors.css';
  composes: bold from '../styles/typography.css';
}

But if i swapped the typography and colors compose statements to make it look like this:

.tooltip {
  composes: absolute block p1 mt1 mb1 top-100 left-50 from '../styles/layout.css';
  composes: bold from '../styles/typography.css';
  composes: white bg-gray from '../styles/colors.css';
}

It then works. This might be an issue as our codebase gets bigger and we start composing more and more.

EDIT: ah, looks like some discussion similar disscussion related to css modules is here: css-modules/css-modules#12

[okonet]

I have same issue. Interestingly, it's not deterministic. It doesn't occur locally but only on the build server.

[BabakMN]

Order in extracted chunk undefined

I can confirm as @okonet said that it is not deterministic I get it randomly between identical builds (multiple runs on same machine same source same config).

Webpack: 1.13.2

[delijah]

+1

[josebalius]

Any updates on this? or is it fixed in the v2 betas?

[emartini]

It can occur on 2.0.0-beta.4. I've been able of make it work sorting the classes that uses CSS Modules compose as @NogsMPLS suggested.

[arrowcircle]

+1 got this error. Any ideas how to solve it?

[felixsanz]

Happens on 2.2.0-rc.2 too. I just run webpack again and it works. Its totally random.

[felixsanz]

@sokra this is a year and half old. Sorry for mentioning you but it is going to be fixed? There is already PR with solutions. What does this need in order to get fixed? What can we do? I feel like we are all just ignored over the months. This bug is not avoidable when using composes from CSS Modules.

[dtothefp]

@bebraw as mentioned in #386 I'm experiencing this issue only when allChunks: true is specified. I've seemed to resolve it with re-ordering my compose statements, I have no idea why this works but probably related to the discussion listed above css-modules/css-modules#12

Consider I have the following helpers that I later compose:

// layout.css
@import 'config/sizing.css';
@import 'config/mediaqueries.css';

//typography.css
@import 'config/colors.css';
@import 'config/sizing.css';
@import 'config/mediaqueries.css';

//fonts.css
@import 'config/sizing.css';
@import 'config/fonts.css';

Now if I make some CSS module classes:

.blurb {
  composes: text-center-medium-up from 'helpers/typography.css';
}

.container {
  composes: margin-auto from 'helpers/layout.css';
}

.caption {
  composes: margin-auto from 'helpers/layout.css';
  composes: calibre-medium from 'helpers/fonts.css';
}

I get the error:

ERROR in ./src/containers/DeepDive/IllustrationBlocks/IllustrationBlocks.css
Order in extracted chunk undefined

ERROR in ./src/containers/DeepDive/IllustrationBlocks/IllustrationBlocks.css
Order in extracted chunk undefined

ERROR in ./src/containers/DeepDive/IllustrationBlocks/IllustrationBlocks.css
Order in extracted chunk undefined

ERROR in ./src/containers/DeepDive/IllustrationBlocks/IllustrationBlocks.css

If I now re-order the class definitions/compose to compose the layout before the typography it works:

.blurb {
  composes: text-center-medium-up from 'helpers/typography.css';
}

.container {
  composes: margin-auto from 'helpers/layout.css';
}

.caption {
  composes: margin-auto from 'helpers/layout.css';
  composes: calibre-medium from 'helpers/fonts.css';
}

Also, it seems the order of the composes for layout and fonts in the .caption class has no effect.

If I do the composes in the same class, order does not seem to matter.

This works!

.container {
  composes: margin-auto from 'helpers/layout.css';
  composes: text-center-medium-up from 'helpers/typography.css';
}

.caption {
  composes: margin-auto from 'helpers/layout.css';
  composes: calibre-medium from 'helpers/fonts.css';
}

and this works too!!

.container {
  composes: text-center-medium-up from 'helpers/typography.css';
  composes: margin-auto from 'helpers/layout.css';
}

.caption {
  composes: margin-auto from 'helpers/layout.css';
  composes: calibre-medium from 'helpers/fonts.css';
}

I have no idea what is going on but for right now it just seems like trial and error or re-ordering classes until they work ¯\_(ツ)_/¯.

Is this error actually an "error" or could it just be made into some sort of warning so the build could still compile successfully?

[bebraw]

@dtothefp I don't understand CSS Modules specification enough to say whether or not that's according to the spec. You could ask them. It's possible the issue is on webpack side as there are a lot of issues like this at the moment (ordering, async, etc.).

[dtothefp]

@bebraw is this in fact an actual "error" that should fail the build from compiling or could it be change to a "warning"?

[bebraw]

@dtothefp Error might be fine. It comes from here. I guess the question becomes, why the modules are sorted wrong in that particular case. If you have time, try to build a small test case to catch your error. That's the first step towards solving this.

[joscha]

@bebraw @dtothefp potentially the test case from #166 could work in order to find the root cause.

[bebraw]

@joscha Thanks for the heads up. I'll try to get some insight from Tobias. I can see it's affecting a lot of people so it would be great to get that PR merged.

[meandmax]

@sokra as far as I know in Webpack 2 there are only objects allowed in the loaders/rules configuration array. Any ideas in how to make your proposed solution work in Webpack 2? As the array for exclusive matching is not allowed? Can I modify the validation of the Webpack config to make this work or what`s your advice here.

Thanks a lot
Max

module.loaders: [
  [
    { test: /\.css/, include: path.resolve(__dirname, "a"),
      loader: ExtractTextPlugin.extract("style-loader", "css-loader") },
    { test: /\.css/,
      loader: "style-loader!css-loader" }
  ]
]

cc @joscha, @timse, @p0wl

[delijah]

Still not working with Webpack 2 :(

[meandmax]

Will this going to be implemented in Webpack 2 or not? @sokra

[delijah]

Seems to work now in version 2.1.0 by using the ignoreOrder config option. Check #166 (comment)

[joscha]

fixed via #166

[keepitreal]

I've submitted #520 to the webpack-1 branch hoping that we can have resolution for those who can't drop everything to upgrade to webpack 2.