Description / Motivation

nx run-many ... works really great for processes that actually end, such as test, lint, build, and so on. However, "watch"-like jobs processes don't exit until the process is either explicitly terminated, errored, or otherwise. It would be great to have a mechanism for these kinds of situations where Nx could either detect when a watch cycle completes (harder/brittle, in my opinion) or helps manage concurrent processes for dependencies, triggering subsequent builds when changes are detected for a specific project. This is particularly critical for projects that are not linked via tsconfig's paths feature.

This could be incorporated/interop with into the current "dependsOn" and "--with-deps" features.

Example:
App X depends on Lib Y, which in turn depends on Lib Z. When running a "serve" job for App X:

• Lib Y and Lib Z would need to be built in "watch" mode
• Lib Z would need to complete at least one build cycle before Lib Y's build cycles start.
• Once at all Lib dependencies have completed at least one build cycle, App X can serve.

Suggested Implementation

It would be hard to work with normal "watch" jobs because they're indeterminate, but I believe Nx could do something like spawn build processes for each dependency graph, triggering subsequent builds when changes are detected for a specific project. The change detection mechanism could use something like chokidar. All of this would follow the topological dependency graph, the same way "dependsOn" and "--with-deps" do today.

Alternate Implementations

Another approach, although I'm worried about its brittleness, would be to have "wait for" parameters and arguments to detect when indeterminate jobs end a build cycle. This however, would require a configurable understanding of what is logged at the end of each watch build cycle.