Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate using a single chokidar instance #210

Open
zertosh opened this issue Apr 24, 2015 · 2 comments
Open

Investigate using a single chokidar instance #210

zertosh opened this issue Apr 24, 2015 · 2 comments
Labels

Comments

@zertosh
Copy link
Member

zertosh commented Apr 24, 2015

Using a single chokidar instance would require changing how watchify "determines" what files to watch. Currently, every file that's part of a build gets its own chokidar instance. This makes the code really straight forward since there is no management of watchers for each basedir - though it's arguable whether this would be a real concern.

To implement a single watcher approach would require: (1) setting up a watcher at the lowest common dir of the build, (2) keeping a list of files that are part of that build, and (3) check on file changes whether that file is in that list. The only real problem that I see with this is that the basedir from browserify's perspective is

var basedir = defined(opts.basedir, process.cwd());

Which in really large projects could include thousands of files. Furthermore, if a required module lives outside of that, say like a global module, monitoring that for changes in a way that pleases everyone is next to impossible.

Motivations:

  1. I have a suspicion that combining callbacks per watched path #201 (comment) and Rebuild does not happen ever #205 might be caused by having so many chokidar instances (basically one per file).
  2. It may or may not consume less resources. @es128 is it better to monitor myproject/*.js (where not all the *.js are of interest, but some are), or to individually monitor each file?
@zertosh zertosh added the todo label Apr 24, 2015
@es128
Copy link
Contributor

es128 commented Apr 28, 2015

Hey @zertosh sorry for the delay in responding.

It is generally better to watch a dir than a file. There may be some very specific circumstances where that isn't true, but for typical use-cases there are potential improvements in both performance and stability by watching project dirs. Note that passing any glob pattern to chokidar will cause the directory to be watched.

In fact, there's a potential change coming that will by default cause directories to be watched even when a single file path is requested by the user to solve issues that may have similar causes to the ones you linked to. In this case, you'd end up gaining most of the benefits of consolidating watchers here without actually having to change any of your code.

There is some relevant history at #106, the result of which was that chokidar now reuses underlying watcher resources on a per-process basis. So there would be very little penalty from continuing to open separate instances that watch nearly the same thing (such as each individual file you care about within a directory).

I would not suggest going with the approach you described of finding the common parent of everything you care about and just watching that, as you do run the risk of watching way way more than you need (as you pointed out when you referred to global modules). You can always use the .add() method to watch additional paths with the same watcher instance.

@zertosh
Copy link
Member Author

zertosh commented Apr 28, 2015

np @es128. thank you so much for the detailed response. I'll play around with your suggestion of using add() for things that fall outside the project's basedir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants