Support "watch mode"

[alexeagle]

We should add a plugin that does the same thing as bazel-watcher.

Give the user commands like

• aspect run //one:target where that target is tagged with ibazel_notify_changes -> like ibazel run //one:target
• aspect test //one:target -> like ibazel test //one:target (??)
• aspect watch //one:target -> like ibazel run //one:target
• aspect watch //target/pattern/... -> like bazel build //target/pattern/...

/cc @achew22

[achew22]

To my naive eye I would like to keep test and watch-test (just to disambiguate) separate. I know a number of people who do not like the ibazel test behavior and I'd hate for them to not be able to use aspect because it doesn't comport with their workflow

[alexeagle]

there's bike-shedding to do for sure. I'd like to avoid hyphenated or modal commands if we can, these will be used so much.

aspect watch //one:target on a test target could be enough if that target is created by a *_test rule?

[achew22]

That seems reasonable to me. I think the usecase of wanting to watch-build (again, I like this red bikeshed) is reasonably uncommon as to make it not worth optimizing. So, 3 modes of operation

1. You've provided a query and it matches multiple targets, so ibazel build them (what about if you want to test them all?)
2. You've provided a single target and it is a _binary, ibazel run it
3. You've provided a single target and it's a _test, ibazel test it

Seems very reasonable to me. Only outstanding question is what if you want to test them all?

[alexeagle]

finally returning to this. I think for 1. we should ibazel test them all, if there are any test targets among the query results.

[Nick-Mazuk]

Another suggestion, we could just add the --watch flag to any of the aspect commands to watch it?

aspect build --watch //directory:target
aspect test --watch //directory:target
aspect run --watch //directory:target

This syntax would also allow users to easily compose the watch flag with custom commands.

aspect lint --watch //directory:target

[alexeagle]

Yes, that's a good point that custom commands might want to participate. Also the scheme above for deciding what bazel watch should mean would need to be communicated with users, and even if the scheme doesn't have flaws, longer documentation can be a clue that we did it wrong.

I think --watch as a flag can be a bit confusing - would you be allowed to put test --watch in your .bazelrc?

OTOH you could put a default for --watch in the BUILD file as a directive on some target (e.g. the devserver should always bazel run in watch mode).

Another concern is to avoid ever having collisions between our flags and Bazel's. We do have a precedent already for flags like --aspect:some_feature but I think watch mode should have a nice terse UI since there are some developers for whom they always run/test this way.

Overall I can totally be convinced to design it that way instead.

[Nick-Mazuk]

Those are all valid points.

Potentially another pattern is to make watch it's own command that can accept all other commands. I can't recall another CLI tool implementing this pattern (essentially "higher-order commands"), but it could be worth considering here.

aspect watch build //directory:target
aspect watch test //directory:target
aspect watch run //directory:target