


The Node application would get absolutely hammered by file system change notifications and slow to a crawl.

At the time, those messages had no throttling behavior. įinally, large file change operations slowed down every operating system. The overall unfamiliarity combined with the different strategies each operating system incorporated, ended up turning the entire project into a spaghetti turd. On Linux and MacOS, issues revolved around unfamiliarity with the file watching API and native constructs.
Node file monitor windows#
NET implementation, I achieved much stronger stability for the Windows operating system. I also encountered strange errors related to having two distinct garbage collectors running concurrently (one for Node and one for the managed file watcher). While this made it quick to get up and running, it inevitably backfired, because some users were unable to run GitKraken due to missing library dependencies. On Windows, I tried using C++/CLI to use the fancier file watching module provided by the.
Node file monitor how to#
With no experience in any of the file watching APIs, little experience in the Native Abstractions for Node (NAN) API, and no clear understanding of how to model the interactions Node makes with each file watching utility, the 0.x.x NSFW releases were, umm, troubled. (RECORD SCRATCH) That’s right, Windows has the best native support. Windows: supports all targeted needs out of the box.MacOS: FSEvents is known to produce inconsistent file events (the file event bitmask becomes corrupted if events occur too quickly), so NSFW stats and disambiguates file change events for you.Linux: The Inotify file watching system does not perform recursive directory watching, so NSFW builds and maintains a recursive watch tree for you.NSFW fills in the gaps for each API so they’re all consistently feature-complete: Since NSFW’s watch utility is targeted specifically at each of those APIs, it means the experience of using the module is consistent across all three OSs.

Linux, MacOS and Windows each ship with their own file watching APIs. This means NSFW doesn’t slow down JavaScript applications, even when they’re under the load of large FS operations. That callback can be throttled internally to prevent spamming the JavaScript/C++ bridge. NSFW queues file events on a separate thread and batches file change dispatches into a single callback. NSFW does most of its work on a separate thread, giving it big performance gains over the built-in Node file system (FS) watcher API. NSFW solves the poor file watching experience on Node by utilizing 3 low-level file watching utilities written in C++ and targeted for the Linux, MacOS, and Windows operating systems.
