Stalker reruns one command when relevant files change. It is useful for local builds, tests, and code generators that should stay up to date while you work.
Install from this checkout with Rust and Cargo:
cargo install --path .Or run it without installing:
cargo run -- --watch . -- cargo testPass one or more paths to watch, then put the command after --:
stalker --watch . -- cargo testKeep watching and rerunning after changes until the command succeeds, then exit:
stalker --watch . --until-success -- cargo testWatch only Rust source files and restart a local server after a 300 ms quiet period:
stalker --watch src --include 'src/**/*.rs' --debounce 300ms -- cargo runRun from another directory, ignore generated files, and wait for the first change before starting:
stalker --cwd /path/to/project --watch . --ignore target --no-initial-run -- make testUseful options:
--watch PATH— path to watch; repeat for more than one path.--include GLOB— rerun only for matching paths, relative to--cwd.--ignore GLOB— skip matching paths, relative to--cwd.--debounce DURATION— wait for changes to settle; defaults to150ms.--no-initial-run— do not run until a relevant change arrives.--until-success— stop watching and exit with code0after the first successful run. Failed runs keep watching for changes.--markers— put machine-readable start and end lines around each run.--raw-output— attach child output directly to the terminal, retaining terminal-aware color and formatting. Cannot be used with--markers.--print-events— print accepted filesystem events to standard error.--no-gitignore— include paths normally ignored by the repository.
Durations use whole-number ms, s, m, or h units, such as 150ms,
2s, or 1m.
Stalker watches the given paths recursively using the operating system's file
watcher. It filters events inside --cwd against the watch roots, your include
and ignore globs, and repository .gitignore rules. Paths watched outside
--cwd are accepted based on their watch roots only; CWD-relative globs and
.gitignore rules do not apply to them. It starts the command once by default,
then groups rapid changes into one rerun after the debounce period.
Only one child command runs at a time. If files change while it runs, Stalker
starts one follow-up run as soon as the current command exits. Child output
passes through unchanged unless you enable --markers.
With --until-success, an exit code of 0 ends the session, including any
queued follow-up run. Nonzero exits, signals, and spawn failures keep watching
for changes. Combine it with --no-initial-run to wait for a change before the
first attempt.