Unexpected: "ERROR in <blah> doesn't export content"

[roblg]

When running ./node_modules/webpack/bin/webpack.js --watch, an error shows up in the terminal after changing a CSS file ("ERROR in doesn't export content"), and the webpack compilation seems to run twice.

The high-level setup is as follows: two entry points, one (OneEntry.js) does a synchronous require of Dep.js, and the other (TwoEntry.js) does a require.ensure of Dep.js. Dep.js requires Dep.css. Changing Dep.css while running with --watch triggers the error message.

The final output doesn't seem to be affected (at least in my simple example here), but it's still a scary message. I started to step through it with node-debug, but didn't get much farther than figuring out where the error was coming from -- line 156 of extract-text-webpack-plugin/index.js. I'll probably look at it at little further tomorrow.

My webpack.config.js:

var ExtractTextPlugin = require("extract-text-webpack-plugin");

module.exports = {
    target: "web",
    debug: true,
    // devtool: "source-map",
    entry: {
        One: './OneEntry.js',
        Two: './TwoEntry.js'
    },
    output: {
        path: "./target",
        filename: "[name].bundle.js"
    },
    module: {
        loaders: [            
            { test: /\.css$/, loader: ExtractTextPlugin.extract("style-loader", "css-loader") },
        ]
    },
    plugins: [
        new ExtractTextPlugin("[name].styles.css")
    ]
};

OneEntry.js

require('./Dep.js');

module.exports = function () {
    console.log("OneEntry");
}

TwoEntry.js

module.exports = function () {
    require.ensure([], function (require) {
        var One = require('./Dep.js');
    });
}

Dep.js

require('./Dep.css');

module.exports = function helloWorld() {
    console.log("Hello, World!");
}

Dep.css

body {
    font-weight: normal;
}

Console output:

[10:30:58] extract-text-plugin-bug-repro$ ./node_modules/webpack/bin/webpack.js --watch
Hash: 1af67a17d8cdba702d4f
Version: webpack 1.4.13
Time: 123ms
         Asset  Size  Chunks             Chunk Names
 Two.bundle.js  3850       0  [emitted]  Two
 1.1.bundle.js   332       1  [emitted]
 One.bundle.js  1886    2, 1  [emitted]  One
One.styles.css    32    2, 1  [emitted]  One
   [0] ./OneEntry.js 81 {2} [built]
   [0] ./TwoEntry.js 113 {0} [built]
   [1] ./Dep.js 103 {1} {2} [built]
    + 4 hidden modules
Child extract-text-webpack-plugin:
        + 2 hidden modules
Hash: 33291634f4065e501d4e
Version: webpack 1.4.13
Time: 24ms
         Asset  Size  Chunks             Chunk Names
 1.1.bundle.js   332       1  [emitted]
 One.bundle.js  1886    2, 1  [emitted]  One
One.styles.css    30    2, 1  [emitted]  One
    + 7 hidden modules
Child extract-text-webpack-plugin:
        + 2 hidden modules
Hash: 2ed4f9458139cfb59089
Version: webpack 1.4.13
Time: 8ms
         Asset  Size  Chunks             Chunk Names
 1.1.bundle.js  1253       1  [emitted]
 One.bundle.js  2807    2, 1  [emitted]  One
One.styles.css    30    2, 1  [emitted]  One
    + 7 hidden modules

ERROR in /path/extract-text-plugin-bug-repro/node_modules/extract-text-webpack-plugin/loader.js?{"omit":1,"extract":true,"remove":true}!/path/extract-text-plugin-bug-repro/node_modules/style-loader/index.js!/path/extract-text-plugin-bug-repro/node_modules/css-loader/index.js!/path/extract-text-plugin-bug-repro/Dep.css doesn't export content

[roblg]

webpack/webpack#589 fixes this simple case, but we're still having issues with a slightly more complicated version. I'll post back here as I know more.

[roblg]

Updating title to reflect that we actually see this error in non-watch mode as well. We have a little hack that seems to fix the issue, but I'm not 100% sure it's the "right" fix.

[roblg]

The original issue posted here said that the output wasn't affected, but it actually does seem to be affected some percentage of the time, which I think increases the severity of the bug.

After some debugging, I made a simple change that seems to fix the issue for us (the error messages go away, and it's been weeks since we had any corrupted output). I'm not entirely sure that the fix is correct -- there might be a better way to accomplish what I did, but I'm hoping someone more familiar with the code than me will take a quick look and be able to tell one way or the other.

Any help/guidance on this would be much appreciated.

Commit: roblg@413f55b

[sokra]

hmm ok I get the issue... If a module is in multiple chunks it is built multiple times in parallel (propably with different intents (one want to extract it, the other not)...

[nighca]

Got this issue, too.
It's not rare that one module being used in multiple places(entries). If it is sync-required (style supposed to be extracted out) in one entry while async-required (supposed not to be extracted) in another, error shows up. Actually error only shows up while watching. If built directly (not watching), no error shows up while the module's style will not be packaged in the async-required chunk.

Hope to know if this will be fixed soon. Thx!

[nighca]

Seems here is the same problem.
#51

[aickin]

I had difficulty applying @roblg's patch to the current codebase. With some tinkering, I was able to kind of sort of get it to work, but it broke hot reload.

Looking a little further into it, it seems like the problem is that the loader declares that its results are cacheable, and then the plugin mutates the results from the loader. When I commented out the two lines in loader that look like this:

if (this.cacheable) this.cacheable();

everything seemed to work fine, including hot reload. I'm not sure if that will cause any other problems, but it seems relatively safe to me. I'll make a PR.

[rosenfeld]

Any updates or work-around for this bug? I had to disable the extract-text plugin for the time being in development (watch) mode and add some conditionals to the application, but I'm afraid bad things might happen in production only since I use a different set-up for the development mode :(

[roblg]

@rosenfeld we ended up following @aickin's advice and making the plugin output non-cacheable.

He had a clever workaround to extend ExtractTextPlugin to fix the behavior -- no funky build-time step needed:

var ExtractTextLoader = require("extract-text-webpack-plugin/loader");

// we're going to patch the extract text loader at runtime, forcing it to stop caching
// the caching causes bug #49, which leads to "contains no content" bugs. This is
// risky with new version of ExtractTextPlugin, as it has to know a lot about the implementation.

module.exports = function(source) {
    this.cacheable = false;
    return ExtractTextLoader.call(this, source);
}

module.exports.pitch = function(request) {
    this.cacheable = false;
    return ExtractTextLoader.pitch.call(this, request);
}

(borrowed from: https://github.com/aickin/react-server/blob/master/packages/react-server-cli/src/NonCachingExtractTextLoader.js; no idea if that link will work forever)

[rosenfeld]

I tried commenting the cacheable line before commenting in this thread and could confirm it worked, but on the other side it got much slower to update the output when the source changes, so I'm not sure whether it's better to disable caching for that plugin or to disable the plugin in watch mode... :(