webpack: Very high CPU usage with new watcher

Now that 1.5 switched to new watcher by default, I noticed it’s using a lot of CPU all the time:

screen shot 2015-01-20 at 14 30 14

It’s not a Gulp issue because it goes away if I use OldWatchingPlugin. It’s also not related to compilation because it happens when Webpack is idle as well.

Any ideas? OS X 10.10.1

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Reactions: 13
  • Comments: 27 (8 by maintainers)

Commits related to this issue

Most upvoted comments

I just ran into this too. You don’t need to run npm install on your whole project again. Just npm install fsevents in the project directory.

OK, let’s presume I did something stupid. Nuking node_modules/webpack and npm install fixed the problem.

Still—I wonder if Watchpack (and Webpack) should now have fsevents as an optional dependency? Otherwise it just doesn’t get installed by default (even if it could be). Or is this not how NPM works?

@gaearon I’m sorry for dusturbing. I’ve just found out the cause of my problem and it doesn’t relate to this topic. The reason it consumed so much CPU was in these lines:

watchOptions: {
    aggregateTimeout: 300, // <---------
    poll: 1000, // <---------
    ignored: /node_modules/
},

I haven’t even seen what they do in docs as the most of the config came from angular2-webpack-starter project. Commenting the lines solves the problem.

150% in watch mode using webpack 4.17.2.

image

The fsevents fix did not work for me, but this did: https://webpack.js.org/configuration/watch/#watchoptions-ignored

If you use yarn you can do yarn add fsevents --optional. This will allow you to save fsevents in package.json but it will not break builds on other platforms.

Optional dependencies are just that: optional. If they fail to install, Yarn will still say the install process was successful. This is useful for dependencies that won’t necessarily work on every machine and you have a fallback plan in case they are not installed (e.g. Watchman).

Solved by simply running npm install fsevents

In my experience, this CPU hogging happens every time I upgrade node.js to a new version, I need to reinstall fsevents (or just nuke the node_modules folder and reinstall)

In case this helps someone else, I was able to fix high CPU usage by doing what gaearon suggested in a previous comment. I had restored a Time Machine backup from Laptop A, on which I previously ran npm install, to Laptop B. On Laptop B, deleting node_modules/ and running npm install brought CPU usage from ~45% down to 0%.

OS X 10.11.3 (on both laptops).

Deleting the entire node_modules folder and npm install fixed the problem for me. Just nuking the webpack folder did not do the trick.

I should keep a note for npm rebuild

@ngyikp in that case, you just need npm rebuild.

Facing the same issue but on Windows 10, and I can’t install fsevents, it’s an OS X-only module… edit: ignoring node_modules solved it for me

It doesn’t seem to lag so much if I explicitly install fsevents so chokidar uses it. Still, it’s about 150% and doesn’t get lower.

Strange, this just started happening to me, running around 270% CPU. Hadn’t happened before, not sure what changed. @tkluysk’s watchOptions comment fixed it for me.