Exception: Cannot read property 'stat' of undefined
llaszkie opened this issue · 10 comments
- Latest version: 1.2.3
- Works fine if downgraded to 1.2.2 (via explicit dev-dependency)
- 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
:
Lines 43 to 47 in 91d2a18
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
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.fs
is exposed for loaders running in a worker or document in the usage that loaders being run in a worker cannot depend on this.fs
.