Webpack isn't noticing your file changes. Did you do something wrong?
Published: 2019-10-25 06:02:17

---
title: Webpack isn't noticing your file changes. Did you do something wrong?
published: true
description: 
tags: 
---


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.

```diff
<<<<<<< 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](https://www.npmjs.com/package/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:

```diff
   "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!