[4.0.0-beta.0] Extracted text being moved to the runtime chunk when using optimization.runtimeChunk

[insin]

Should this plugin attempt to detect and ignore the chunk Webpack 4 creates when you use optimization.runtimeChunk?

I haven't been able to reproduce a minimal project for this yet, but while working on nwb's webpack4 branch I've configured optimization.runtimeChunk = {name: 'runtime'} and allChunks: true and am building project which has a code split which imports CSS. My build somehow ends up emitting a runtime.[hash].css file instead of moving CSS from the code split to the entry chunk.

Dropping the following into the top of mergeNonInitialChunks():

console.log({chunk: chunk.name, intoChunk: intoChunk && intoChunk.name})

Output is:

{ chunk: 'app', intoChunk: undefined }
{ chunk: 'Child1', intoChunk: 'app' }
{ chunk: 'Child2', intoChunk: 'app' }
{ chunk: 'runtime', intoChunk: undefined }
{ chunk: 'Child1', intoChunk: 'runtime' }
{ chunk: 'Child2', intoChunk: 'runtime' }

As a quick test, I tried filtering out the runtime chunk at the top of the optimizeTree hook in apply() using the specific name I gave it in my config and things worked as expected again.

[DNLHC]

Not sure if my issue is relevant, but after upgrading i'm getting separated css + sourcemaps for vendors, runtime and entry files.

[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