Downloads
Watchexec CLI
Latest release: 2.7.0 (2026-08-24)
Release notes
Watchexec now only traverses and watches directories that are expected to produce events (according to filter/ignore files and patterns). This means that if you have a very large directory tree, and 90% of it is gitignored, Watchexec will no longer go through and add watches to that 90% at all. Thus:
- startup in those cases should be much faster and less resource-intensive
- ongoing performance should also improve (as there will be vastly fewer events to process), though that may be less perceptible
The way this is achieved is by handling all directory traversal/recursion within Watchexec, instead of letting the Notify library handle it. This is a large amount of work and code, and it's expected that there will be new bugs as a result. However, this limitation was also the underlying source of a number of long-standing bugs, and I quite look forward to close some very old issues as a result.
:; hyperfine 'watchexec-2.7.0 -1 echo' 'watchexec-2.6.1 -1 echo'
Benchmark 1: watchexec-2.7.0 -1 echo
Time (mean ± σ): 158.9 ms ± 2.2 ms [User: 199.6 ms, System: 63.3 ms]
Range (min … max): 155.8 ms … 163.1 ms 18 runs
Benchmark 2: watchexec-2.6.1 -1 echo
Time (mean ± σ): 387.1 ms ± 2.4 ms [User: 157.5 ms, System: 366.3 ms]
Range (min … max): 382.0 ms … 390.0 ms 10 runs
Summary
watchexec-2.7.0 -1 echo ran
2.44 ± 0.04 times faster than watchexec-2.6.1 -1 echo
(The -1 option is a hidden test-only option which starts watchexec normally, runs the command, and exits.)
On BSD, the kqueue backend has been disabled; those platforms will use polling instead. kqueue is not designed for this kind of thing, and using it thus has significant downsides, such as heavy kernel resource usage, as well as correctness bugs. FreeBSD 14 and up have native inotify support; Watchexec does not yet take advantage of this but will in the future (it comes in with Notify 9, which is currently in RC).
Watching a single file no longer stops watching it when it is replaced (#190). Similarly, though this is less common, if a folder being watched (using -W or -w) is deleted and recreated, Watchexec used to lose the watch and no longer produce events. That was because the watch was placed on the file (or folder) object, not on a pathname string, and replacing the object naturally makes the watch disappear along with the old version of the object. Watchexec now watches from one path segment above, so it can notice when a watch gets replaced; because it also does directory tree filtering, this is not significantly more expensive.
Cargo Watch
Latest release: 8.5.3 (2024-10-02)
Release notes
This is the final release of Cargo Watch.
Cargo Watch is now dormant: it will not receive further updates, but does remain available.
I (@passcod) currently have very little time to dedicate to unpaid OSS. There is a significant amount of work I deem required to get Watchexec (the library) to a good-enough state to bring its improvements to Cargo Watch, and that has been the case for years without a realistic end in sight. I have had dwindling motivation in the face of having spent 10 years on or around this project and its dependencies (it was a long while ago, but once upon a time the Notify library was spun off from Cargo Watch!), when at the very start, this tool was only made to clear a quick hurdle that I'd encountered while trying to code other, probably more interesting, yet now long-forgotten Rust adventures.
However, not all is lost, dear users. For almost the entire life of the project, I have had a thought: that someone with more resources, skill, time, and/or the benefit of hindsight would come around and make something better. Granted, I thought this would happen to Notify. But Notify has persisted, has been passed on to live a long life, and instead the contender is Bacon.
I have had no involvement in Bacon. Yet it is everything I have wanted to achieve in Cargo Watch. Indeed some five years ago I started development on a Cargo Watch replacement I called "Overwatch", which would have a TUI, a tasks file, a rich pager, and more long-desired features. That never eventuated, though a lot of the low-level improvements that I wrote in preparation for Overwatch "made it" into Notify version 5 and the Watchexec library version 2.
Bacon today is what I wanted Overwatch to be.
Let's face it: Cargo Watch has gone through too many incremental changes, with too little overarching design. It sports no less than four different syntaxes to run commands. Its lackluster filtering options can be obnoxious to use. Pager support is non-existent, sometimes requiring arcane invocations to get right. It can conflict with Rust Analyzer (which didn't exist 10 years ago!), though that has improved a lot over the years.
It's time to let it go.
Use Bacon.
Remember Cargo Watch.
Watchexec is also available for a similar experience that will continue to be maintained, albeit slowly.
Discuss at https://www.reddit.com/r/rust/comments/1ftc7cj/cargo_watch_is_on_life_support/