A bunch of other excellent similar projects have been linked here, and here's mine - a general purpose tool that lets you put together flexible responses to file system change:
The use case here is deep and interesting, and I don't know of any tool that gets it 100% right. HN is often quick to grumble about reinventing the wheel, but where there is no clearly correct solution I think we should encourage experimentation.
Modd is my opinionated take: it differs from other tools by trying to have a "proper" configuration language in which you can embed shell commands, by separating prep commands (that run and complete) and daemons (that run, but might need to be restarted on change), and by being completely agnostic about languages, test methodologies and other specificities of external tools.
I always get anxiety when I read about these tools. In Windows, the kernel drops file update notifications all the time. There is a fixed sized buffer for them and overflows do happen.
I've not read the Linux code for them, but I think the implementation is probably similar.
I keep hearing this repeated, but when I've ran tests on this in the past (ReadDirectoryChangesW is the name of the function, if I recall correctly) it was actually quite difficult to lose messages.
For normal user behavior you will rarely encounter a problem. But build systems tend to update/create files very quickly. If there was a workload which would break ReadDirectoryChanges, it would be this one.
Reading the code for Realize, he gets the directory watching facilities from https://github.com/fsnotify/fsnotify. That library seems to drop the 'buffer overflow, please reset your assumptions' message. So if it did happen, I don't think the user would have a good experience.
If you do ever depend on ReadDirectoryChanges, you do need to fallback to stat-ing files if you get an overflow. Otherwise, your milage may vary.
https://github.com/cortesi/modd
The use case here is deep and interesting, and I don't know of any tool that gets it 100% right. HN is often quick to grumble about reinventing the wheel, but where there is no clearly correct solution I think we should encourage experimentation.
Modd is my opinionated take: it differs from other tools by trying to have a "proper" configuration language in which you can embed shell commands, by separating prep commands (that run and complete) and daemons (that run, but might need to be restarted on change), and by being completely agnostic about languages, test methodologies and other specificities of external tools.