You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
varbasedir=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.
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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
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:
myproject/*.js
(where not all the *.js are of interest, but some are), or to individually monitor each file?The text was updated successfully, but these errors were encountered: