[rush] Design Proposal: Phased Command Hook Rework

[dmichon-msft]

Summary

For future extensions of phased commands and more optimal interaction with long-running watch sessions, it would be useful to build on the recent change that gives Operation the enabled: boolean property to split createOperations into createOperations and configureOperations, where the job of the latter is purely to set enabled to true or false depending on scoping parameters, and createOperations builds the graph of all operations that might be in scope.

This then would tie into having the control flow be:

createOperations();
while (!terminated) {
  executeOperationsAsync(...);
  if (isWatch) {
    waitForChanges()
  } else {
    return reportErrorsAndSetExitCode()
  }
}

Where

// `operations` passed via instance property so that plugins can invoke this method
executeOperationsAsync(snapshot) {
  configureOperations(this.operations, snapshot)
  beforeExecuteOperations(...)
  async parallel for (const operation of operationQueue) {
    beforeExecuteOperation(op);
    execute(op);
    afterExecuteOperation(op);
  }
  afterExecuteOperations(...)
}

[dmichon-msft]

@aramissennyeydd , @elliot-nelson , @chengcyber , in particular I'm interested to know if only generating the graph once is likely to break any of your workflows/custom plugins.
The motivation here is that I want to start moving Rush into a world where the build engine can be orchestrated via interactive UX, and to do that, I need to have some persistent objects that I can associate with their "most recent status", for which the Operation instances are a natural fit.

One effect of this will end up being that they will decide at execution time whether they are running "clean" or "incremental", rather than during graph definition.

[aramissennyeydd]

I think this makes sense, would this impact the set of operations that createOperations would return for various selectors, ie

1. --from: would createOperations return the full build graph and then configureOperations would only turn on the specific sub-graph corresponding to the selector?
2. --to-except: would this be the --to graph with the final node turned off?