Skip to content

Webpack hanging when importing multiple files with the same dependency #99

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rbhalla opened this issue May 18, 2015 · 7 comments
Closed

Comments

@rbhalla
Copy link

rbhalla commented May 18, 2015

I have 3 .js. files, importing 3 separate .scss files. Each .scss file however imports the same (variables) file.

When I try and run webpack now, it hangs. If I remove the variables file dependency from any of the files, it suddenly works. In any of the .js files, if I stop importing the .scss file, it works.

Does anyone have any idea of what might be causing this?

My webpack config in case it helps:

webpack({
  entry: src.js.entry,
  output: {
    path: dist.root + dist.js,
    fileName: 'bundle.js',
    chunkFilename: '[id].chunk.js',
    publicPath: '/' + dist.js
  },
  resolve: {
    modulesDirectories: [src.node, src.bower, src.css.root],
    extensions: ['', '.js', '.jsx', '.json']
  },
  module: {
    loaders: [
      { test: /\.jsx?$/, exclude: /node_modules|bower_components/, loader: 'babel' },
      { test: /\.css$/, loader: 'style!css' },
      { test: /\.(scss|sass)$/, loader: 'style!css!sass' + '?outputStyle=expanded&' +
        "includePaths[]=" +
          (path.resolve(__dirname, src.bower)) + "&" +
        "includePaths[]=" +
          (path.resolve(__dirname, src.node))
      },
      { test: /\.(png|jpg|jpeg|gif|svg)$/, loader: 'url?limit=10000' },
      { test: /\.json$/, loader: 'json' },
      { test: /\.(woff|woff2)$/, loader: 'url?limit=100000' },
      { test: /\.(ttf|eot)$/, loader: 'file' },
    ]
  },
  debug: true,
  devtool: '#inline-source-map',
  plugins: [
    new webpack.optimize.CommonsChunkPlugin('common.js'),
    new webpack.ResolverPlugin([
        new webpack.ResolverPlugin.DirectoryDescriptionFilePlugin("bower.json", ["main"])
    ])
  ]
}, function(err, stats) {
  if (err) throw new gutil.PluginError('webpack', err);
  gutil.log("[webpack]", stats.toString());
  cb();
});
@rbhalla
Copy link
Author

rbhalla commented May 18, 2015

I'm embarrassed to admit I spent the majority of my day making no progress with this bug. I couldn't replicate it with a simpler setup so I'm assuming it's an edge case bug to do with my dependency graph.

Regardless, downgrading to 0.4.3 with node-sass 2.1.1 fixed it. If someone does figure out the mysterious cause of this bug please do let me know.

@rbhalla rbhalla closed this as completed May 18, 2015
@eugene1g
Copy link

@rbhalla I encountered a similar issue in a complicated project, and also could not replicate it with a simple example I could post here for debugging. Eventually I narrowed it down to an issue in node-sass that hangs the process if it has to compile more than 5 files simultaneously (see sass/node-sass#857). In a multi-threaded model, including the same dependency in a complex graph triggered that problem for me.

The solution that worked for me was to temporarily override the limit in Node during the execution of webpack+sass loader. In my OSX pipeline it looks like this:

$ env UV_THREADPOOL_SIZE=55 webpack-dev-server --config webpack-devserver.config.js --colors --port 9020 --hot

To make the process easier, I created a Makefile like so:

front-server:
    env UV_THREADPOOL_SIZE=55 webpack-dev-server --config webpack-devserver.config.js --colors --port 9020 --hot

front-build:
    env UV_THREADPOOL_SIZE=55 webpack --config webpack-production.config.js

Then I can just run "$ make front-server" and it will launch the dev server, or "$ make front-build" to compile for production.

In your case it looks like you are using your own middleware (instead of webpack-dev-server), so perhaps "$ env UV_THREADPOOL_SIZE=55 node myassetcomipler.js" will work for you.

edit: This worked with node-sass v3.* and sass-loader v1.*

@jhnns
Copy link
Member

jhnns commented May 20, 2015

Probably also related to #100?

@rbhalla
Copy link
Author

rbhalla commented May 20, 2015

@jhnns Yes that's the exact behaviour I was experiencing.

@eugene1g I haven't had a chance to confirm your findings but it does sound along the correct lines. Thanks for your writeup, I will test it out as soon as I can.

@newtonianb
Copy link

Same problem, how exactly do you set UV_THREADPOOL_SIZE?
I'm running gulp which runs webpack so where do I put this?

@jorrit
Copy link
Contributor

jorrit commented Jul 27, 2015

Either run your gulp command with UV_THREADPOOL_SIZE=100 gulp or execute process.env.UV_THREADPOOL_SIZE=100 in your gulp file before executing webpack.

@javivelasco
Copy link

Oh God! Been dealing with this the whole *** day until I've found out it's sass thing and came here. Thank u guys, UV_THREADPOOL_SIZE=100 working nicely!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants