Add cargo watch

[Zerotask]

Describe the problem you are trying to solve

During development you are very often in the process of making changes and then build or run your project or run your tests. This always costs some time, therefore an automation would be useful, to save some time and increase the developer experience

Describe the solution you'd like

I'd like to have a built-in watcher similar to nodemon for NodeJS or like this project https://github.com/passcod/cargo-watch
This would allow you to run your whole project if you change something or you can also specify to run only tests when your files change:
cargo watch -x run
cargo watch -x test

Since this is completely optional to use, developers are not forced to use the suggested watcher.

Notes

[sr2ds]

@Zerotask, I usage the cargo-watch package and is like nodemon. Why do you think that is necessary include this on cargo if the package cargo-watch solve this problem?

When I need make any tests without cargo, I run on homemade script like this:

while inotifywait -e close_write *; do rustc main.rs; done

Sorry if I did not understand correctly your request.

[Zerotask]

Yes, I also mentioned this package and the reason why I think it should be added to the default toolchain of cargo.

If a command is often used, one could consider to add it to the default toolchain.

[sr2ds]

Yes! I understand your wish now and this make sense. I use every day cargo watch too.

[reinaldorauch]

Hello, i'm interested in implementing this feature into cargo and as discussed in this forum post, I'm moving the conversation here.

So, for starters I think this feature being a "simple" flag option to the cargo run command that just restarted the command when some file in the project (the src dir and its files, by default) is changed. I'm investigating on how cargo-watch and the others does the things.

I'm ok with things taking time, i would just appreciate some advice, if any has some.

[weihanglo]

Just note that Cargos has a function list_files respecting package.include and package.exclude. This might be worth a reuse than inventing a brand new file listing mechanism. There are also change detection instructions in build scripts we need to consider. O

To be fair, I don't know any details of cargo-watch. epage's suggestion seems like a great starting point to me.

[epage]

Another thing I'd add is to study multiple forms of prior art for features, pitfalls, etc so and report on them and what you suggest we should apply from them.

We do this when adding commands but I suspect a --watch flag has enough little pieces of policy to be worth it as well.

[epage]

While this might only be implemented a bit at at time, we should consider what all commands should support this.

Speaking of a bit at a time, a plan for implementing this, at least from MVP to what you care about.

[reinaldorauch]

I think the MVP should only care about of watching for files changes under src (or respectives if not a binary package) and then recompile it as of cargo run and maybe also limit the scope of it to binary packages (because it most worth it when developing a web server, for example)

[zzz6519003]

High-priority

[weihanglo]

@zzz6519003 it helps nothing leaving a comment like “High-priority”. At this moment, cargo-watch and its underlying watchexec-cli are good alternatives before a first-party subcommand comes out. They both work seamlessly to me.

---

Copied from epage's comment:

By "adding" cargo watch to cargo, I think integrating it as a --watch flag is included in that. Probably first thing is a thorough understanding of cargo watch and what works well and doesn't. Besides having a general idea that you want this, we need an understanding of what that means in practice. The discussion should likely continue on that linked issue.

I think it is what to do next if someone wants to give it a try. Further more, you might want to go through a (pre-)RFC process or similar to solicit community feedback. In addition, commands other than build can also benefit from watch mode, so we should make the scope of the MVP and the future extension clearer. For example, do we want to have Cargo in daemon mode? Is it related to how watch mode is integrated? As a good reference, you can check how cargo <file> -Zscript has been done.

---

Triage: in terms of technical details, the MVP needn't be a perfect one. I'd say the efforts level almost reaches “hard” but let's make it a medium one for now.
@rustbot label: +E-medium +S-needs-design

[passcod]

Hey found out about this thread from someone linking me https://blog.rust-lang.org/inside-rust/2024/02/13/this-development-cycle-in-cargo-1-77.html — happy to answer any queries y'all might have.