React App Compilation failing due to missing eslint cache file

[dylanrhysscott]

Can you reproduce the problem with latest npm?

Yes

Description

React app compilation is periodically / intermittently failing with the error due to a change in eslint-caching as per #1578. A cache file is missing in the node_modules directory

Expected behavior

App should compile with no errors

Actual behavior

The create-react-scripts throw the following error when compiling on file change:

Module build failed: Error: ENOENT: no such file or directory, open '/app/client/node_modules/.cache/eslint-loader/data.json'

On closer inspection this seems to happen when I rename / add a new file. However it happens so randomly it has been difficult to pin down.

Environment

Run these commands in the project folder and fill in their results:

1. npm ls react-scripts (if you haven’t ejected):

npm info it worked if it ends with ok
npm info using npm@4.1.2
npm info using node@v7.6.0
client@0.1.0 /app/client
`-- react-scripts@0.9.2

npm info ok

2. node -v:

v7.6.0

3. npm -v:

4.1.2

1. Operating system: OSX running Docker Image: https://hub.docker.com/r/dylanrhysscott/docker-react-dev/ which is based off of official node images

2. Browser and version: Chrome 56.0.2924.87 (64-bit)

Ping @Timer - Here's the issue. I can't provide my project as its on a private Git server internally but will do all I can to help troubleshoot. Hope this helps!

[dylanrhysscott]

One other thing I forgot to mention is - I'm using YARN rather than NPM directly. Could this also have an effect? My version of YARN is: 0.20.3

[viankakrisna]

hmm, is the process running in a container that reads host filesystem?

[dylanrhysscott]

@viankakrisna It's using a shared volume which mounts my source code yeah. I've been using this custom image for a while with a few other projects and not had issues. It downloads the latest version of the create-react-scripts at runtime. Is it worth doing a quick copy into the container avoiding the volume mount?

[viankakrisna]

Yup, can you try that? also, does setting the env CHOKIDAR_USEPOLLING=true helps? I think there are some delay between the filesystem and the watcher process. It helps in the vm, i don't know if it's also true in the docker

[dylanrhysscott]

@viankakrisna Hmmm just inspected my node_modules directory and the required json file is there. I did run an automated build which grabbed a fresh copy of the node base image just to rule that out. Looking at the last update to the node base image I was up to date anyway. The eslint-loader directory is there where it was missing before. Reinstalling the node_modules and it is still there. Possible my usage of YARN didn't actually install all the required folders? Or the watcher wasn't creating it due to volume delays? I will keep messing until I can get a definitive cause for you if there is one

[dylanrhysscott]

I appreciate the docker usage is probably outside your remit :)

[viankakrisna]

yup, can you also try the CHOKIDAR_USEPOLLING? need to rule out all option before fire up a docker image to dig on that. Here's the link to do that https://github.com/facebookincubator/create-react-app/blob/5155797983476260a6e6e8d93ca38b43233d82de/packages/react-scripts/template/README.md#npm-start-doesnt-detect-changes

[gaearon]

Looking at the eslint-loader implementation of caching, it seems to miss error handling in a few crucial places. For example, when writing the file, or when potentially creating a directory.

If babel-loader can't create a directory in node_modules, it will fall back to OS directory. However, eslint-loader could fail here, and the fallback will never kick in.

If babel-loader's cache gets deleted while the server is running, it will still attempt to create a directory before writing a file. eslint-loader will only do this once and not for subsequent writes even though the cache might have been deleted. And failing to write the file on subsequent writes will crash it instead of trying to fall back to OS directory like babel-loader does.

It seems like eslint-loader implementation of caching could use some error handling work. It would be awesome if someone could fix it up in a few days, but if not, we’ll likely revert the option because it’s just not as reliable as the Babel option.

[dylanrhysscott]

@gaearon Hi Dan, Thanks for the breakdown. I currently can't replicate this issue as the eslint-loader directory is being created with data.json seems to be an edge case. Will keep an eye on this issue and will update my images when a fix is available.

[RohovDmytro]

Bumped into this issue. Super frustrating 😞

[RohovDmytro]

From what I noticed: this issues consistently appears after yarn-installing new module.

[viankakrisna]

confirmed that this is consistently happening after yarn installing new module. I'm digging on it right now