1

I'm having issues with Webpack resolving module names on Windows. The loaders are installed, but the path Webpack is using to try to resolve them is incorrect (notice the fact that it's concatenated the module path to the working directory below). Webpack is being launched with webpack-dev-server. 

ERROR in ./~/css-loader?sourceMap&modules&localIdentName=[name]_[local]_[hash:base64:3]!./~/postcss-loader?parser=postcss-scss!./client/src/scripts/components/Main/Main.css
Module build failed: (SystemJS) ENOENT: no such file or directory, open 'C:\Users\Terry\Projects\django-react\C:\Users\Terry\Projects\django-react\node_modules\css-loader\index.js'
        Error: ENOENT: no such file or directory, open 'C:\Users\Terry\Projects\django-react\C:\Users\Terry\Projects\django-react\node_modules\css-loader\index.js'
            at Error (native)
        Error loading C:/Users/Terry/Projects/django-react/C:\Users\Terry\Projects\django-react\node_modules\css-loader\index.js
 @ ./client/src/scripts/components/Main/Main.css 4:14-225 13:2-17:4 14:20-231
 @ ./client/src/scripts/components/Main/Main.jsx
 @ ./client/src/index.js
 @ multi main
webpack: bundle is now VALID.

Relevant info:

  • Windows 10
  • Node 6.6.0
  • I'm running webpack with babel-node via NPM script
  • Webpack 2.1.0-beta.22
  • NPM 3.10.3

EDIT: this usually only happens when I make an edit that triggers a hot reload. Sometimes it happens when I launch webpack-dev-server the first time, but it happens every time I edit the source.

terry87
  • 445
  • 1
  • 4
  • 15

1 Answers1

2

Not sure if you ever figured this out, but I was running into the same exact error with the malformed node_modules path when using webpack on Windows 10. I was very disappointed to find that nobody was able to solve this since this particular error does not seem to be documented anywhere else.

In my own debugging I found that this error only happens with webpack loader modules, so I dug into webpack to track down where the error was coming from. After some digging it turned out that this was caused by the loader-runner package used by webpack. It attempts to use System.import to resolve the loader module, with a fallback on require when System.import is not available. In my case, the malformed node_modules path was being generated by System.import via systemjs. It appears that the systemjs implementation of System.import has a bug when absolute paths are used on Windows, and since webpack passes an absolute path for loaders, it throws an error.

I was able to work around this by editing my local copy of loader-runner, and comment out the System.import, forcing it to use require instead. This is, of course, not a good long term solution by any means so I am still looking for something better. I just tried switching to yarn to see if maybe this is an npm dependency issue, but this workaround should get you up and running if you're still getting these errors on Windows.

blobcat
  • 21
  • 2
  • FWIW, I dropped back to a non-beta version of Webpack (i.e. 1.x), which worked, so I didn't pursue it much further. I ended up Great job tracking down the problem. – terry87 Dec 20 '16 at 16:22