App breaks on subsequent webpack compilations when using loader

[nixedmelon]

I just migrated from webpack v1 to webpack v3 with not much issue. However, I'm running into a really annoying problem that seems to stem from extract-text-webpack-plugin when webpack-dev-server re-compiles after the initial compile.

Here's what's happening:

1. I start webpack-dev-server
2. Webpack compiles bundle
3. Navigating to index works fine - application works just as it did when using webpack v1
4. I make a change to a JS file
5. Webpack re-compiles bundle with no errors; browser refreshes
6. Application no longer works. Upon closer inspection, it seems extract-text-webpack-plugin "overwrites" variables.

If I don't use extract-text-webpack-plugin during loading, the issue doesn't happen.

I've attached a GIF below to illustrate the issue. You can see that, on initial load, the Inferno object is correctly set with its required functions. On reload, it's not:

My webpack config:

const webpack = require('webpack');
const ExtractTextPlugin = require('extract-text-webpack-plugin');
const Dotenv = require('dotenv-webpack');

module.exports = {
	entry: './src/index.jsx',
	output: {
		path: __dirname + '/build',
		filename: 'bundle.js'
	},
	devtool: 'inline-source-map',
	resolve: {
		extensions: ['.js', '.jsx']
	},	
	module: {
		rules: [
			{
				exclude: /(node_modules)/,
				test: /\.jsx$/,
				use: [
					{
						loader: 'babel-loader',
						options: {
							presets: ['es2015', 'stage-0'],
							plugins: [
								"babel-plugin-syntax-jsx",
								"babel-plugin-transform-object-rest-spread",
								["babel-plugin-inferno", { imports: true, pragma: "" }]
							],
							babelrc: false
						}
					}
				]
			},
			{
				test: /\.scss$/,
				use: ExtractTextPlugin.extract({
					fallback: 'style-loader',
					use: ['css-loader', 'sass-loader']
				})
			},
			{ 
				test: /\.woff(2)?(\?v=[0-9]\.[0-9]\.[0-9])?$/,
				use: [
					{
						loader: 'url-loader',
						options: {
							limit: 10000,
							mimetype: 'application/font-woff'
						}
					}
				]
			},
			{ 
				test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
				use: [
					{
						loader: 'file-loader'
					}
				]
			}
		]
	},
	devServer: {
		host: "0.0.0.0",
		contentBase: './public/app',
		port: 8080,
		noInfo: false,
		//hot: true,
		inline: true,
		historyApiFallback: true
	},
	plugins: [
		new ExtractTextPlugin('./style.css'),
		new Dotenv({
			path: './.env.local'
		}),
		//new webpack.HotModuleReplacementPlugin()
	]
};

Here are my dev depedencies:

"devDependencies": {
	"babel-core": "^6.25.0",
	"babel-eslint": "^6",
	"babel-loader": "^7.1.1",
	"babel-plugin-inferno": "^3.1.0",
	"babel-plugin-syntax-jsx": "^6.18.0",
	"babel-plugin-syntax-object-rest-spread": "^6.13.0",
	"babel-plugin-transform-object-rest-spread": "^6.23.0",
	"babel-preset-es2015": "^6.24.1",
	"babel-preset-stage-0": "^6.24.1",
	"css-loader": "^0.26.1",
	"dotenv-webpack": "^1.5.3",
	"eslint": "^4.3.0",
	"extract-text-webpack-plugin": "3",
	"file-loader": "^0.11.2",
	"font-awesome-sass-loader": "^2.0.1",
	"glob": "^7.1.1",
	"inferno-devtools": "^3",
	"node-sass": "^4.5.0",
	"sass-loader": "^6.0.6",
	"style-loader": "^0.13.1",
	"url": "^0.11.0",
	"url-loader": "^0.5.9",
	"webpack": "^3.1.0",
	"webpack-dev-server": "^2.6.1"
}

[fuwaneko]

I have the same issue. In the resulting bundle after first recompile original module position in array of modules is replaced by some random stuff (in my case css-base.js from css-loader takes index 1 where isArray from lodash should be, but webpack require function for isArray keep trying to get it at index 1) which results in broken app. Disabling extract-text fixes it.

This renders webpack's watch mode unusable.

I also think it's related to #584.

[crdx]

I'm experiencing the exact the same problem as fuwaneko.

After the first build the module in position 1 is one vue-loader depends on that exports a method named normalizeComponent. Once it rebuilds this module's been replaced with css-base, which wasn't even in the original bundle. The vue-loader dependency is now nowhere to be found in the resulting bundle.

For now I've worked around it by downgrading to extract-text-webpack-plugin@2.1.2.

[fuwaneko]

@crdx I also experience same vue-loader problem sometimes. Broken isArray is one thing, some parts of app still work. But broken vue-loader prevents app from working at all.

[stephennancekivell]

My team is also experiencing this problem and I can confirm that when I downgrade to extract-text-webpack-plugin@2.1.2 It resolves the problem. I've tried with webpack 3.4.1 & 3.5.2.

[baldlion]

Also experiencing this issue - downgrading to 2.1.2 resolves the problem

[cletusw]

Can anyone provide a minimum but complete repro case for this issue? I'm working on whittling mine down but it may take a while.

[cletusw]

@d3viant0ne Here's my minimal repro case.

https://github.com/cletusw/extract-text-webpack-plugin-issue-579

It appears to be a complicated interaction between extract-text-webpack-plugin, css-loader, and externals. Although maybe someone else will be able to whittle it down further. I was unable to.

[cletusw]

@evilebottnawi @d3viant0ne Can we remove the Needs repro tag for this one since I've provided a minimal repro case?

Also, any idea how long this will take before it can be addressed? Thanks.

[alexander-akait]

@cletusw sorry, no idea 😞 but you can investigate this and send PR 👍

[jjinux]

In order to work around this issue, I:

• Forked.
• Created a branch starting from 2.1.2.
• I applied the following patch in order to work around [webpack v3.0.0] generates CSS in wrong order #548.

diff --git a/index.js b/index.js
index 75ef621..d6af64b 100644
--- a/index.js
+++ b/index.js
@@ -320,7 +320,12 @@ ExtractTextPlugin.prototype.apply = function(compiler) {
                compilation.plugin("additional-assets", function(callback) {
                        extractedChunks.forEach(function(extractedChunk) {
                                if(extractedChunk.modules.length) {
-                                       extractedChunk.modules.sort(function(a, b) {
+                                       // HACK: Fix the CSS ordering issue present in 2.1.2 without needing to move to
+                                       // version 3.0.0 which breaks reloading in webpack-dev-server.
+                                       // See: 
+                                       //      https://github.com/webpack-contrib/extract-text-webpack-plugin/issues/548
+                                       //      https://github.com/webpack-contrib/extract-text-webpack-plugin/issues/579
+                                       extractedChunk.modules = extractedChunk.modules.sort(function(a, b) {
                                                if(!options.ignoreOrder && isInvalidOrder(a, b)) {
                                                        compilation.errors.push(new OrderUndefinedError(a.getOriginalModule()));
                                                        compilation.errors.push(new OrderUndefinedError(b.getOriginalModule()));

I'm not sure if it'll hold up, but until this issue is resolved, this may unblock me from moving to Webpack 3. Thanks to @kevinzang for the idea.

[JayCanuck]

Awesome idea @jjinux That sorting issue was the one big issue I had with downgrading (plus the npm package.json wanting webpack 2.x). Would you be able to share your fork url?

[jjinux]

Sorry, @JayCanuck, I created a private fork in my company's GitHub team. Hopefully, my description above will allow you to do the same.

[editedredx]

Created a fork containing the workaround from jjinux if anyone needs it for now until it's fixed:
https://github.com/editedredx/extract-text-webpack-plugin/tree/bug-579-workaround

[alexander-akait]

@editedredx can you describe your fix or do PR (better)?

[editedredx]

Sorry @evilebottnawi, this is hardly a fix for this problem, just a workaround to make plugin version 2.1.2 work with webpack 3. I only applied the diff from jjinux.
I can make a pull request from my current branch if you want but I don't think it'll help fix this issue.

[alexander-akait]

@editedredx can we fix this using your solution for 3 version?

[editedredx]

@evilebottnawi No because this solution is not a fix for the problem only a downgrade to when the problem did not exist.

[mightyaleksey]

I guess I faced the similar issue. I have configured hot reload with a plain css-loader configuration and looks like that subsequent update corrupts the modules graph, which results in loading wrong chunks by old ids.

[JayCanuck]

Webpack 3.6.0 appears to have fixed the issue for me. I think anyway (fingers crossed).

[lukasgeiter]

Webpack 3.6.0 also fixes the problem for me 🎉

[michael-ciniawsky]

webpack/webpack@0975d13

[ForkInSpace]

updating Webpack to the latest version also helped, which is Webpack 3.11.0 at the time of posting.
@lukasgeiter it seems they fixed the issue since 3.5.5 release (the version I was running earlier)