Webpack isn't noticing your file changes. Did you do something wrong?

Have you ever felt personally attacked by Webpack, or ESlint, or Visual Studio Code? Not in the normal, every day ways, but in the special way where it's telling you "this file can't be parsed" but you can see with your own, human eyes that the error is just plain wrong?

It seems like this happens a different way every time. Last week, maybe it was a merge conflict.

<<<<<<< HEAD
// my good, new code
=======
// somebody else's bad, new code
>>>>>>> master

You resolved it, and saved the file, and can see everything is normal now! But...

  1:2  error  Parsing error: Unexpected token

> 1 | <<<<<<< HEAD

That's not true! I solved the problem! You try canceling and re-running npm start. You try restarting your terminal, or VS Code, or your entire computer. This makes no sense!

Your neighbor tells you: "Oh yeah, sometimes I have to delete my node_modules, and npm install. Or sometimes I have to delete the project, and git clone it again." That sucks, you say. That's not a good answer! What's the real problem behind the scenes?

You're suffering from a stale file cache. And I have great news: it's easy to diagnose and even easier to resolve. Don't delete your node_modules directory! ESPECIALLY don't delete your project! Delete node_modules/.cache. Run npm start again. Check. Is everything back to normal?

At the root of this madness-inducing bug is the find-cache-dir package. It's a great tool: multiple projects use it to find and use the node_modules/.cache directory to store temporary cache files for performance reasons. And it's great when it works, which is most of the time. babel-loader uses it, so does eslint-loader. These are the two I've seen cause similar errors and confusion in the past, but I'm sure there are others.

But sometimes, when you make an unexpected change, the cache gets confused. You fixed the git merge conflict and removed those <<<<<<< HEAD tags, but maybe the file that imported the conflicted file is still using the stale, cached copy. It's okay, deleting the node_modules/.cache directory will make any packages using it read everything fresh the next time they run. And it'll solve this issue, and you can continue being productive.

If you find this is happening often in your project, you can add an npm script to make this a quicker fix:

   "scripts": {
     "start": "react-scripts start",
     "build": "react-scripts build",
+    "nuke:cache": "rm -rf ./node_modules/.cache",
     "test": "react-scripts test",
     "eject": "react-scripts eject"
   },

You can also make the new script cross-platform. Run npm install -D rimraf to install the rimraf package to your devDependencies, and change the script to "nuke:cache": "rimraf ./node_modules/.cache".

Now you can run npm run nuke:cache whenever the issue comes up again.

Let me know in the comments if you've ever run into this problem. And let others know about the fix, because nobody should ever have to lose time or work to a misunderstood caching issue!