fix(graph): tolerate workspace package-ordering cycles

[semimikoh]

Fixes the false "Cycle dependency detected" reported in voidzero-dev/vite-plus#1610 and discussed in #411.

Problem

vp run --filter/-r hard-errors on workspaces where two siblings reference each other through a non-runtime link — e.g. app depends on builder while builder lists app under peerDependencies (the nuxt / @nuxt/vite-builder shape).

pnpm builds the same workspace fine: it keeps every dependency kind in its graph and tolerates cycles by collapsing the cyclic packages into a single chunk that runs together, failing only under --disallow-workspace-cycles.

Approach

Per @branchseer's analysis in #411, the gap is structural (hard-error vs cycle tolerance), not edge filtering. After the task execution graph is built, a new IndexedTaskGraph::break_package_ordering_cycles finds each cyclic strongly-connected component and drops the package-ordering edges inside it — edges that have no corresponding dependsOn edge in the task graph. The cyclic tasks then run together with no ordering between them, mirroring pnpm's chunk behavior.

The executor and the acyclic-execution-graph invariant are unchanged: package-ordering cycles are already broken before ExecutionGraph::try_from_graph runs, so a remaining cycle there can only be an explicit dependsOn cycle.

Test plan

• New plan-snapshot fixture workspace_cycle_tolerated (covers both a peerDependencies and a devDependencies back-edge) plans cleanly instead of erroring.
• Existing cycle_dependency fixture (explicit dependsOn cycle) still errors — snapshot unchanged.
• cargo test, cargo clippy --workspace --all-targets --all-features -- -D warnings, cargo fmt --check, and cargo doc -D warnings all pass locally.

Open questions (marked draft)

1. Explicit dependsOn cycles still hard-error (preserves existing behavior). Is that the desired split, or should those be tolerant too?
2. No --disallow-workspace-cycles opt-in parity yet — happy to add as a follow-up if wanted.

[wan9chi]

Thanks! This is a clever solution! Please let me take my time to think about it.

[wan9chi]

Hi @semimikoh. Thanks for the PR again, but I think we need more considerations on the fix.

I pushed a plan snapshot test workspace_cycle_chunk_order / preserves_external_chunk_order to demonstrate the problem:

The fixture is:

graph TD
  consumer --> b
  a --> b
  b --> a
  a --> base

Loading

pnpm would treat a and b as one cyclic chunk, so the effective order is [base], then [a, b], then [consumer].

The generated snapshot shows a limitation of this PR's fix: after the internal a <-> b edges are removed, the cycle is tolerated, but the surrounding chunk order is not preserved.

Concretely:

• a#build depends on base#build
• b#build has no dependency on base#build
• consumer#build depends only on b#build

So b can become ready before base, and consumer can become ready before a.

I honestly don't have a clean solution in mind yet, but suggestions are very welcome.