ek9_check_module_cycles
Answers first: hasCycles and cycleCount, then cycles[] (each a closed module path with edges[].via naming the source files) and moduleCount - the whole workspace module graph.
When to use it
Are there circular references between the modules of this package - one call, no arguments; hasCycles and cycleCount answer it.
When not to use it
- Cycles BETWEEN published packages (cross-package) - use
ek9_check_package_dependency_cycles. - The full module dependency graph, not just cycles - use
ek9_query_module_dependencies(cycles are a subset of that data). - Dependency-injection wiring cycles (compile error E08190) - use
ek9_query_diagnostics.
Details
cycles[].modules uses the closed-path convention (["A","B","A"] means A -> B -> A; the repeated first module marks closure, not a distinct node). moduleCount is how many modules the walk covered. edges[].via lists the source files whose imports create each cycle (jump-to-source); reliable detection and via-attribution need a compile that reached SYMBOL_DEFINITION or later — at syntax_only hasCycles is only a lower bound.
Arguments
None of its own.
Recorded calls
Real calls, recorded against small projects and checked on every build - a changed answer fails it.
Clean shape
Request
{ }
Response
{
"cycleCount" : 0,
"cycles" : [ ],
"hasCycles" : false,
"meta" : {
"serverMs" : "<timing>"
},
"moduleCount" : 1
}
Cycle shape
Request
{ }
Response
{
"cycleCount" : 1,
"cycles" : [ {
"description" : "cycle.beta → cycle.alpha → cycle.beta",
"edgeCount" : 2,
"edges" : [ {
"from" : "cycle.beta",
"to" : "cycle.alpha",
"via" : [ "<workspace-root>/Beta.ek9" ]
}, {
"from" : "cycle.alpha",
"to" : "cycle.beta",
"via" : [ "<workspace-root>/Alpha.ek9" ]
} ],
"modules" : [ "cycle.beta", "cycle.alpha", "cycle.beta" ]
} ],
"hasCycles" : true,
"meta" : {
"serverMs" : "<timing>"
},
"moduleCount" : 2
}