[webpack2] loader modules resolved only from root

If I have config:

module: {
  loaders: [
    {test: /\.css$/, loader: 'style!css'}
  ]
},
resolve: {
  modules: ['node_modules', __dirname + '/client/node_modules'],
  moduleExtensions: ["-loader"],
}

if install style-loader into /client/node_modules It will not find it, and have to install it to /node_modules. Though resolution from /client/node_modules works inside app’s code.

[guybedford]

@sokra thanks for copying me in. I’m not completely sure I follow the details, but perhaps you can ensure that the System global is overridden before using the loader-runner? SystemJS originally didn’t override System if it didn’t already exist, but we had to add override behaviour because Traceur was overriding the global System. Unfortunately we’ve passed this virus on 😃

[sergei-startsev]

@bebraw It’s still relevant, I came across this issue with webpack 2.2.0-rc.7. I use systemjs and systemjs-builder modules together with webpack in scope of one node.exe process. Here’s the output of failed webpack bundles:

Module build failed: (SystemJS) ENOENT: no such file or directory, open 'd:\\<local_path>\\d:\\<local_path>\\node_modules\\babel-loader\\lib\\index.js'
    Error: ENOENT: no such file or directory, open 'd:\\<local_path>\\d:\\<local_path>\\node_modules\\babel-loader\\lib\\index.js'
        at Error (native)
   Error loading d:/<local_path>/d:\\<local_path>\\node_modules\\babel-loader\\lib\\index.js

I’ve tried to get rid of systemjs dependencies and webpack worked properly for me. As a temporary solution I’ve removed global variable System:

delete global.System;

SystemJS Builder doesn’t use that global variable, so it looks like it doesn’t affect it, anyway I’ve not caught any issues.

@whitecolor Does it make sense to reopen it?