`vp run --filter` reports a false cycle when sibling packages are linked via peer/devDependencies

[semimikoh]

Summary

vp run --filter ... derives its workspace ordering from the package graph. Currently, that graph treats dependencies, devDependencies, and peerDependencies as ordering edges.

As a result, when two workspace packages reference each other through a peerDependencies or devDependencies link, the back-edge is rejected by the task planner as a cyclic dependency, even though there is no real build-order cycle.

pnpm and turbo do not treat a peerDependencies link as a build-order edge, so the same workspace builds successfully there.

Reported downstream at voidzero-dev/vite-plus#1610.

Reproduction

Reproduction: https://github.com/danielroe/vp-cycle-repro

Workspace shape:

• app → builder via dependencies
• builder → app via peerDependencies

Commands:

pnpm install
pnpm --filter './packages/' build
vp run --filter './packages/' build

pnpm succeeds in topological order, while vp run fails with:

Cycle dependency detected: app#build -> builder#build -> app#build

pnpm install warns about the cyclic workspace links but completes, and the build itself runs fine.

Root cause

As of rev 5833b37, the package graph adds an edge for every dependency kind: Normal, Dev, and Peer.

In crates/vite_workspace/src/package.rs:49-54:

• dependencies → DependencyType::Normal
• dev_dependencies → DependencyType::Dev
• peer_dependencies → DependencyType::Peer

Then, in crates/vite_workspace/src/lib.rs:194, add_edge(id, dep_id, dep_type) adds all three dependency types to the graph.

Topological ordering for vp run is derived from that package subgraph without filtering by dependency type. In crates/vite_task_graph/src/lib.rs:26-27, the code notes that topological ordering is handled at query time via the package subgraph rather than by pre-computing edges in the task graph.

However, crates/vite_workspace/src/package_graph.rs builds the induced subgraph with () edge weights through full_subgraph / build_induced_subgraph. This drops the original DependencyType weight without filtering.

The comment there already anticipates type-aware filtering:

Future --filter-prod support would skip DependencyType::Dev edges at this point.

Finally, the execution graph hard-errors on any cycle, unlike vp exec, which tolerates cycles through a Tarjan SCC fallback. That is why only vp run surfaces this issue.

Relevant locations:

• crates/vite_task_plan/src/execution_graph.rs — AcyclicGraph::try_from_graph
• crates/vite_task_plan/src/error.rs:176 — Cycle dependency detected: ...

In short, the peerDependencies back-edge from builder to app is promoted into the build-order graph, and the planner aborts even though peerDependencies should not impose build order.

Proposed fix

The package graph already carries DependencyType on each edge, but that information is discarded when the induced subgraph is built in package_graph.rs.

Filtering at the subgraph-construction point would keep the fix localized.

The main change should be:

• Exclude peerDependencies edges from the build-order subgraph.

A peer dependency does not impose a build or install order. This matches pnpm and turbo behavior, and removes the false cycle directly.

devDependencies may need to be discussed separately. They may still be useful for ordering in some cases, but they should probably not create a hard build cycle by themselves. This also aligns with the existing --filter-prod direction already noted in the code.

Suggested test

A plan snapshot fixture should be enough, since this issue is about task graph ordering and cycle detection rather than task execution.

Suggested fixture location:

crates/vite_task_plan/tests/plan_snapshots/fixtures/

The fixture can use a two-package workspace:

• app depends on builder through dependencies
• builder references app through peerDependencies

Expected result:

vp run should plan cleanly instead of failing with a cycle error.

System info

• vp 0.1.21
• pnpm 11.0.9
• macOS arm64

[wan9chi]

FWIW, pnpm doesn't exclude peerDependencies from ordering. It builds edges from every dependency kind (peer always, dev unless prod), then tolerates cycles when sorting by collapsing the cyclic packages into one chunk instead of throwing. So run --filter just runs the sorted chunks with no cycle error, and pnpm only fails on a cycle behind --disallow-workspace-cycles, otherwise it warns.

Confirmed this with the exact shape from the repro (app → builder via dependencies, builder → app via peerDependencies) on pnpm 10.33. pnpm install warns There are cyclic workspace dependencies: .../app, .../builder, and pnpm --filter './packages/**' build then runs both packages in parallel as a single chunk (their build windows fully overlap), with no ordering between them and no error.

The structural difference is that vite-task plans an acyclic execution graph and hard-errors on any cycle, while pnpm sequences packages into ordered chunks (levels) and just groups cyclic packages into the same chunk. That's why the same workspace builds under pnpm but not here.

---

Generated by Claude Code

[semimikoh]

@branchseer
You're right, thanks for clarifying.

I checked pnpm's implementation, and it matches what you described:

• projects-graph keeps edges from peerDependencies, devDependencies unless ignoreDevDeps is enabled, optionalDependencies, and dependencies.
• graph-sequencer tolerates cycles by returning cyclic nodes as a single chunk rather than throwing.
• hard failure is opt-in via --disallow-workspace-cycles; otherwise pnpm warns and continues.

So my initial idea of excluding peer/dev edges from the build-order subgraph is not the right fix. It would diverge from pnpm's behavior and could also drop legitimate devDependency ordering.

The real difference seems structural: vite-task currently plans a strictly acyclic execution graph and fails during cycle detection, while pnpm sequences packages into ordered chunks and collapses a workspace cycle into a single chunk with no internal ordering.

A better direction would be to keep the package graph edges as-is, tolerate cycles that come from workspace package ordering by grouping the cyclic tasks into the same execution level, and continue to hard-fail on explicit dependsOn task cycles.

Does that match the behavior you'd want here?

[semimikoh]

@branchseer

Implemented your suggested direction in #414 — keeps all edges and just drops the package-ordering edges inside a cyclic SCC so the cyclic packages run together. Explicit dependsOn cycles still error. Would appreciate your review.