Allow service to be passed as argument for tye run --watch (like --debug)

[razvangoga]

What should we add or change to make your life better?

Because i'm generally interested in watching one or two of my dotnet services not all of them.
To align cli behaviour between --watch and --debug

Why is this important to you?

See above

[philliphoff]

Given that moving to --watch <services> would be a breaking change (e.g. for existing scripts, the VS Code extension, etc.), I'm not sure there's an overriding benefit. Whereas --debug <services> has real impact to the user (as the startup behavior differs/halts based on the setting), --watch should mostly be invisible to the user (until a change is made) whether one service is watched or all.

Is there a specific reason why a user might not want a specific service being watched or where it might be problematic? If so, I wonder whether it might make sense to either (1) try to make the behavior backward compatible (e.g. --watch be equivalent to --watch *) or (2) use a different argument (e.g. --watch means all services, while --watchServices <services> allows the user to be explicit).

[razvangoga]

As far as i remember (i wrote this point down some 9moths ago -> https://gist.github.com/razvangoga/971767f1fa9c7684edbe2fbcaaa2db8e ) i've had strange issues when running watch on a config with a lot of services (15+ dotnet + others (containers / node)). Running a non watch worked fine. Can't remember if it was on win or on mac (we had guys in the team on both). I guess i could try to repro it.

In any case, i see your point about the backcompat - i would prefer the 1st version where --watch is taken as --watch * instead of just adding a new prm.

[philliphoff]

@razvangoga That's fair. I think I've seen issues, in particular, when multiple services reference the same set of common libraries (i.e. races in the parallel builds kicked off by watch). I'm ok with an explicit means to indicate the services to watch aside from the concern about impact to existing scripts/tooling, and user experience (--watch being easier to remember/type than --watch *). If there's a way to make --watch work the same, then agree that'd be the best option.

[razvangoga]

Yeah, I think that was it - we had a project setup in which a core lib (or a bunch of them) was (were) shared between 3 surface processes (a webapi, a worker service and a cli that would run the EF migrations) - all of them were started via tye.