Very high CPU usage with new watcher

[gaearon]

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

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

[gaearon]

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.

[sokra]

@gaearon Is it lower for small projects? Maybe the watcher count is linear to CPU usage...

@gaearon Could you verify if fsevents is really used by chokidar?

fsevents should cause low cpu usage on OS X according to @paulmillr https://twitter.com/paulmillr/status/448600421054291970

Chokidar call: https://github.com/webpack/watchpack/blob/master/lib/DirectoryWatcher.js#L21-L27

[gaearon]

It's strange.
Even without fsevents, I have this issue in one project but not the other.

I'm not sure what the difference is yet.
I removed most of the source files but it's still 50% CPU, whereas other project works fine.

I'll keep investigating..

[gaearon]

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?

[sokra]

chokidar has it as optional dep: https://github.com/paulmillr/chokidar/blob/master/package.json#L46

So theoretically it should be installed if possible when installing chokidar...

[paulmillr]

yeah everything is cool this way

[onpaws]

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).

[josephg]

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.

[laggingreflex]

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

[mistercrunch]

For the record, nuking node_modules/webpack and running npm install also fixed this for me.

[lexkrstn]

What should I do on Windows 8.1 to solve the issue?

• fsevents is an OSX-only module and I cannot install it on Windows.
• Nuking node_modules/webpack and installing it again didn't help.

All the time webpack-dev-server is running it's process consumes about ~30% of CPU.

[gaearon]

@CoderLex Have you tried this? webpack/watchpack#23

[lexkrstn]

@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.

[winterbe]

npm install fsevents fixes the issue, however putting fsevents into package.json breaks builds on other platforms, e.g. linux. So you have to remember that every time you rm -rf node_modules && npm install you also have to do npm install fsevents.

My brain is lazy so chances are good I totally forget about in a couple of weeks. 😭

[Jessidhia]

chokidar (the indirect dependency that depends on fsevents) will install it on its own, an an optionalDependency.

The only case fsevents may not be picked up is if you're using a shrinkwrap generated in a non-mac machine. OTOH, if you do use a shrinkwrap generated in a mac, npm install itself will fail on non-macs, so pick your poison.

[onpaws]

@winterbe I feel the same way about keeping dependencies obvious. Why not make a note in your package.json?

Because JSON doesn't support comments some folks have come up with alternative approaches.

[ngyikp]

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)

[Jessidhia]

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

[msmfsd]

Thanks @gaearon for this fix, saved my day 👍

[maartenscholz]

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).

[chemzqm]

I should keep a note for npm rebuild

[GotJimmy]

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

[hosembafer]

Solved by simply running npm install fsevents

[danburzo]

Is this still relevant? If so, should we add a canonical solution to the docs?
I've done this:

yarn add --optional fsevents
rm -rf node_modules
yarn

and it does seem to help, but I'd love to know if these commands are actually doing anything useful or it's just magical thinking :-)

[tkluysk]

150% in watch mode using webpack 4.17.2.

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

[davidcalhoun]

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.

[tonix-tuft]

npm install fsevents did it for me. Thank u guys!