Repository navigation
[rushd][WS0] Upstream engine prerequisites (in rush-lib) #5895
Copy link
Copy link
Open
Labels
Description
Land the watch-mode overhaul and adapt in-repo plugins so the engine exposes a stateful, warm-able operation graph the daemon can own.
Depends on: #5378 (provides the stateful IOperationGraph)
Scope
- Merge the watch-mode overhaul ([rush] (BREAKING CHANGE) Overhaul watch-mode to facilitate orchestration #5378). Land the stateful
IOperationGraph(setEnabledStates,scheduleIterationAsync,executeScheduledIterationAsync,invalidateOperations,abortCurrentIterationAsync,closeRunnersAsync),OperationGraphHooks(onIdle,onExecutionStatesUpdated),IPCOperationRunner, and the reworkedProjectWatcher— replacing the disposableOperationExecutionManagerwith a graph that persists across iterations. - Migrate in-repo plugins. Move
CacheableOperationPlugin,ShardedPhaseOperationPlugin,OperationResultSummarizerPlugin,ConsoleTimelinePlugin,PhasedOperationPlugin,IPCOperationRunnerPlugin,rush-serve-plugin,rush-bridge-cache-plugin, andrush-buildxl-graph-pluginonto the new hooks. - One warm full-workspace graph. Build the graph over all workspace projects with a client's selection applied as an enabled subset (
includeAllProjectsInWatchGraph) so the daemon keeps a single warm graph and scopes it per request. - Per-iteration runner lifetime. Lift the persistent-vs-one-shot choice out of static
IPCOperationRunnerPluginconstruction into a per-iteration host decision — keep hot runners resident for warm projects; tear cold ones down immediately at operation completion. - Follow-up (non-blocking). Converge rush-lib's
OperationGraphonto the standalone@rushstack/operation-graphlibrary.
Acceptance criteria
- The stateful
IOperationGraphandOperationGraphHooksare merged and exported, with the public API captured in the committedrush-lib.api.md. - All existing phased-command and watch-mode behavior is preserved; updated snapshots are intentional and reviewed.
- Every in-repo plugin compiles and passes its tests against
OperationGraphHooks(no plugin depends on a removed/renamed hook except through the optional compat shim in WS5); cache, sharding, summary, and timeline outputs are unchanged. - A full-workspace graph can be built once and an arbitrary selection enabled via
setEnabledStateswithout rebuilding; disabled projects stay resident (watchable/invalidatable) but unscheduled. - The host can choose persist vs one-shot per operation per iteration (default unchanged when unspecified); a non-persistent runner is torn down immediately at its operation's completion, before downstream operations run.
- (Follow-up, not on the critical path) rush-lib consumes
@rushstack/operation-graphwith no behavioral change. - Breaking hook renames/relocations are recorded in the WS5 migration guide + API changelog; new engine behavior ships opt-in / dead-code until cutover; unit/integration tests green in CI.
Part of #5894.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNeeds triage
Activity
dmichon-msft commentedon Jul 22, 2026
There are some complexities to the rushd vs. watch mode interactions vis-a-vis which phases are in scope. We don't currently have an "all possible phases" mode, and the dependency graph nodes and edges are both allowed to vary depending on the command being invoked (via plugins modifying the graph, notably).