Dependency graph validation shared by the publishing plan and the analysis tasks.
Builds the graph, detects cycles by type, and computes the publishing order,
reporting cycles and sort failures in the result rather than throwing, so
each caller decides how to surface them: the plan turns them into errors,
gitops_analyze and gitops_validate format them.
See also: dependency_graph.ts for the core graph data structure and algorithms.
4 declarations
graph_validation.ts view source
(repos: LocalRepo[]): RepoAnalysis import {analyze_repos} from '@fuzdev/fuz_repos/graph_validation.js'; Builds the dependency graph and runs cycle/wildcard analysis, tolerating cycles
(reports rather than throws). The shared core of gitops_analyze and
gitops_validate, which format the result themselves.
reposLocalRepo[]RepoAnalysis graph_validation.ts view source
GraphValidationResult import type {GraphValidationResult} from '@fuzdev/fuz_repos/graph_validation.js'; graphtype DependencyGraph
publishing_ordertype string[]
production_cyclestype string[][]
dev_cyclestype string[][]
sort_error?Why the topological sort failed, when it did; publishing_order is then empty.
type string
graph_validation.ts view source
RepoAnalysis import type {RepoAnalysis} from '@fuzdev/fuz_repos/graph_validation.js'; graphtype DependencyGraph
analysistype DependencyAnalysis
publishing_orderTopological publishing order, or null when prod/peer cycles prevent ordering.
type string[] | null
graph_validation.ts view source
(repos: LocalRepo[]): GraphValidationResult import {validate_dependency_graph} from '@fuzdev/fuz_repos/graph_validation.js'; Builds the dependency graph, detects cycles, and computes the publishing order (prod/peer dependencies only, so dev cycles don't block it).
Never throws on cycles: a production/peer cycle leaves publishing_order empty
and sets sort_error, and the caller reports it.
reposLocalRepo[]GraphValidationResult the graph, publishing order, and detected cycles