This library seems to be a great fit for things like cargo watch which are continuously watching and waiting. However, it was a bit harder to integrate with a build system like Buck/Bazel, which typically want to know all changes at the start of a build (when the user types build), then build ignoring file system changes thereafter (or sometimes pick them up at the end to warn the user). That means that instead of having events that arrive at some point (potentially racing with other operations such as the user typing build), and instead of polling at a defined interval (for the polling watcher), it would be useful to have a poll or flush method on Watcher that ensured all in-flight notifications were delivered (e.g. flush the underlying file descriptors or similar) and in the case of the poll watcher, polled immediately at that point.
This library seems to be a great fit for things like
cargo watchwhich are continuously watching and waiting. However, it was a bit harder to integrate with a build system like Buck/Bazel, which typically want to know all changes at the start of a build (when the user types build), then build ignoring file system changes thereafter (or sometimes pick them up at the end to warn the user). That means that instead of having events that arrive at some point (potentially racing with other operations such as the user typing build), and instead of polling at a defined interval (for the polling watcher), it would be useful to have apollorflushmethod onWatcherthat ensured all in-flight notifications were delivered (e.g. flush the underlying file descriptors or similar) and in the case of the poll watcher, polled immediately at that point.