Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Uses a ton of CPU in polling mode #2
I'm developing an app and switching over to using Docker containers for some of it. Since I'm running OS X, I'm running Docker in Vagrant and using NFS to share my working directory, then building containers from the code in that directory.
It can be difficult to find a file watcher that works properly over NFS. Nodemon fails, pm2 eats up CPU, but node-supervisor seems to do well by just doing a slow poll. I get great <1% CPU usage watching with supervisor.
Unfortunately, webpack-dev-server with the old watcher doesn't catch changes at all, so I'm using
I've played around with the invocation of Chokidar in
I stuck a logging statement at the invocation of Chokidar and found that it's watching about 90-100 directories; every single module my project imports, as well as all of the project folders. It's easy to see how, with polling, this could get expensive.
Is it possible to:
The solution doesn't have to be super-elegant; this is just a dev environment.
For reference, regarding working around this, here's what I came up with to get the webpack dev server to play nicely with the remote host:
I serve the frontend on port 80 of
The webpack config has a
Additionally when adding the dev server (this code is adapted from one of the webpack boilerplates), I set the client path to localhost:
entry = joinEntry("webpack-dev-server/client?http://localhost:2002, entry);
This feels really hacky but it works and keeps my laptop much cooler since FSEvents is so much more efficient than 100 pollers over NFS.
referenced this issue
Jun 14, 2015
I did a trace to figure out what's going on so after looking at this
it seems that webpack (Compiler.js + NodeWatchFileSystem.js) is requesting a watch on every file that the build depends on, including node_modules.
which basically will "forward" watch options down the stream.
Which one would you prefer?
On OS X, I've also noticed that it's easy to break the
Here's a little bash script https://gist.github.com/aripalo/6d659fefc79dee72e8e3 that fixes the issue until #23 is merged and available in npm registry.