arizona_watcher implementation on the fs library (inotify on Linux, FSEvents on macOS, the Windows API on Windows).

Add the package to a dev-only rebar3 profile and name it in the arizona reloader env:

%% rebar.config
{profiles, [{dev, [{deps, [arizona_watcher_fs]}]}]}.

%% config/dev.config
{arizona, [
    {reloader, #{
        enabled => true,
        watcher => arizona_watcher_fs,
        rules => [#{directory => "src", patterns => [".*\\.erl$"],
                    callback => fun arizona_reloader:reload_erl/1}]
    }}
]}.

It takes no options.

Events

fs reports raw events; a path counts as changed on created, modified, deleted, or renamed (the inotify MOVED_TO). The last is what an atomic-rename save produces -- write a temp file, then rename() it over the target -- which is how vim, sed -i, and most editors and agent file-writers save. Two events are left out: a directory rename (renamed with isdir) is not a source-file edit, and a file moved out of the directory (removed, the inotify MOVED_FROM) is delete-like with its path now absent.

Lifecycle

Each watch is a named fs instance (fs registers its processes, so the name is an atom derived from the calling process and the directory) whose supervisor is linked to the calling rule process, so a crashing watch stops the rule and its supervisor restarts it. fs runs an OS process (sh + inotifywait on Linux) with the watched directory as its cwd; terminate/1 shuts the instance down and waits for it, so a caller that deletes the watched directory right after does not race its getcwd.

The fs application itself is never started: its default env starts a recursive watcher on the node's working directory. That is why fs is a dependency of this package but not in its applications.