Unexpected: "ERROR in <blah> doesn't export content" about extract-text-webpack-plugin

[dalimian]

I was having same issue (latest webpack and extract-text-plugin), the workaround to disable cache did not work for me. Making this change in .../node_modules/extract-text-webpack-plugin/index.js did the trick

if(shouldExtract !== wasExtracted) {
to
if(shouldExtract && !wasExtracted) {

issue in my case was that it was trying to recompile when shouldextract was false and wasExtracted was true

Also it looks like in my case, aside from having a named entry including same css as an async chunk, this issue was only happening for me when my webpack config had two instances of new ExtractTextPlugin(...) in the plugins[]

[kostasmanionis]

Is anyone still experiencing this with 3.0.0 ? @dalimian suggestion fixes the issue for me

[siebertm]

I also see this issue in our - admittedly rather large - codebase. To rule out as much as possible (in terms of other dependencies), I set out to create a more minimalist test case project.

I was able to quickly reproduce the issue using the code found at https://github.com/siebertm/extract-text-webpack-loader-issue-42-testcase.

As @nighca already said, the issue seems to have something to do with the sync vs async require. In my test codebase, a.js requires common.js asynchronously (using require.ensure())
while b.js requires common.js synchronously (using require())

I'd like to help out more but I simply don't understand what and how the loader does what it does...

[andreechristian]

+1, require.ensure problem?

[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... :(

[rosenfeld]

@roblg, I'm curious. How do you combine this loader with other loaders? The documentation talks about using the extract method and inform the other loaders (style, css and sass in my case). I don't know how to combine this loader class with other loaders...

[rosenfeld]

Nevermind, got it to work already.

[thebigredgeek]

#169

[mnpenner]

I'm experiencing this issue with --watch periodically now too.

[missyjcat]

Here's a proposed fix following @aickin's suggestion that allows an isCacheable flag to be passed into the options. It worked for our implementation but we'd prefer not to fork and patch the plugin: #251

weird though, the build is failing in Node 0.12 both in the CI and on my laptop, but it's failing on master too.

[Crazymax11]

what's about PR merging?

[JulianJorgensen]

@kostasmanionis I was still experiencing it when I ran rimraf (yarn clean). Now it is gone - after adding this line to .yarnclean

!svgo/.svgo.yml