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.
@koistya the code requires
postcss-import
, which requirespostcss-import\lib\resolve-id
->pkg-resolve
->jspm\api
->systemjs-builder
->systemjs
the
systemjs
package adds a globalSystem
which is used then bywebpack
->loader-runner
to load loaders.dependency hell😄
Not sure who to blame:
pkg-resolve
because it depends on jspm.systemjs
because it registers a global System (may be hidden behind asystemjs/register
).loader-runner
because it usesSystem.import
.System.import
impl bysystemjs
because it doesn’t handle absolute paths.cc @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 overrideSystem
if it didn’t already exist, but we had to add override behaviour because Traceur was overriding the globalSystem
. Unfortunately we’ve passed this virus on 🙂@bebraw It’s still relevant, I came across this issue with
webpack 2.2.0-rc.7
. I usesystemjs
andsystemjs-builder
modules together withwebpack
in scope of onenode.exe
process. Here’s the output of failed webpack bundles:I’ve tried to get rid of
systemjs
dependencies andwebpack
worked properly for me. As a temporary solution I’ve removed global variableSystem
: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?