webpack-contrib/cache-loader

Exception: Cannot read property 'stat' of undefined

llaszkie opened this issue · 10 comments

  1. Latest version: 1.2.3
  2. Works fine if downgraded to 1.2.2 (via explicit dev-dependency)
  3. The error occurs during vue-service-cli build for a project

Please check the declaration of module dependency.

Module build failed (from ./node_modules/thread-loader/dist/cjs.js):
Thread Loader (Worker 10)
 Cannot read property 'stat' of undefined
     at toDepDetails (C:\agent\_work\2\s\node_modules\cache-loader\dist\index.js:65:14)
     at arrayIterator (C:\agent\_work\2\s\node_modules\neo-async\async.js:3780:9)
     at timesSync (C:\agent\_work\2\s\node_modules\neo-async\async.js:2292:7)
     at Object.mapLimit (C:\agent\_work\2\s\node_modules\neo-async\async.js:3775:5)
     at Array.<anonymous> (C:\agent\_work\2\s\node_modules\cache-loader\dist\index.js:88:18)
	 at arrayEachFunc (C:\agent\_work\2\s\node_modules\neo-async\async.js:2512:19)
     at Object.parallel (C:\agent\_work\2\s\node_modules\neo-async\async.js:6867:9)
     at Object.loader (C:\agent\_work\2\s\node_modules\cache-loader\dist\index.js:87:9)

@llaszkie can you create minimum reproducible test repo? Looks not all fs have stat method

@evilebottnawi See vuejs/vue-cli#2847
The missing of this.fs is caused by thread-loader if i'm not mistaken.

@sodatea strange, feel free to investigate and send a PR with fix, really very strange

Experienced this issue with the @Vue/cli when creating a new project and trying to build

yes i also have the same issue while trying to run build for the project

I think the this.fs.stat here should be fs.stat:

this.fs.stat(dep, (err, stats) => {
if (err) {
mapCallback(err);
return;
}

I came across this problem when I build my app on travis CI. Since I didn't push yarn lock file, which reference to cache-loader 1.2.2. And that's why my local test passed.

Please don't spam i also have the same issue, just use 👍 or better send a PR with fix

Somebody can create minimum reproducible test repo?

This will be resolved by by #45

But I wonder if this is actually a bug in the thread-loader, either in the code or in the documentation.

this.fs is clearly documented in the loader API. It seems like an odd precedent to set that every webpack loader needs to be thoroughly tested in the context of all other webpack loaders, especially when some webpack loaders essentially erase part of the API.

I think that the thread-loader should either make sure that this.fsis exposed for loaders running in a worker or document in the usage that loaders being run in a worker cannot depend on this.fs.

Fixed by #45. Released in v1.2.4 🎉