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.
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:
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.