ek9_query_dependency_tree
Answers first: direction, rootPackage, rootVersion, then tree{} (dependsOn) or deduplicated[] with broughtInBy (broughtInBy), selections[] and summary - the transitive package dependency tree across the workspace.
When to use it
What does this package pull in transitively, or why is module X pulled in - one call, no arguments for the whole tree. For the 'why', pass direction:'broughtInBy' and moduleFilter:'X'.
When not to use it
- YOUR DECLARED deps only (no transitive expansion) — use
ek9_query_package. - You want module-level imports WITHIN your package, not the external dep tree — use
ek9_query_module_dependencies. - You specifically want CYCLE DETECTION across the tree — use
ek9_check_package_dependency_cycles. - You want to TRIGGER a resolution / fetch rather than query an existing one — use
ek9_resolve_dependencies.
Details
In-workspace scope: only packages whose source is in the compiled workspace are expanded; external deps appear as leaves with selectionNote 'external (not in workspace)'. direction:'dependsOn' is the nested DOWNWARD subtree ('what does X depend on?'), direction:'broughtInBy' the flat list with the UPWARD broughtInBy[] set ('what brings X in?'); format (nested | flat) is the same choice by shape, and giving both when they disagree is an error. moduleFilter is one exact module name (or a prefix with a trailing *): nested roots the subtree at the first match, flat keeps the matching modules; an unmatched filter still succeeds with a null/empty tree. selections[] lists each module's selected version; rejectedVersions[] is currently always empty (no remote version-conflict resolution), and revisited modules are pruned with selectionNote 'already present at shallower depth'.
Arguments
| Argument | Type | Required | What it is |
|---|---|---|---|
direction | string: dependsOn | broughtInBy | dependsOn (default): the downward tree from the root or the filtered module; broughtInBy: the flat list with, per module, the packages that pull it in. | |
format | string: nested | flat | Output shape: nested (hierarchical tree, = dependsOn) or flat (deduplicated list with broughtInBy, = broughtInBy). Optional when direction is given. | |
moduleFilter | string | Optional: one exact module name, or a prefix with a trailing *. dependsOn: the subtree rooted at the first match; broughtInBy: the matching modules with their broughtInBy. |
Recorded calls
Real calls, recorded against small projects and checked on every build - a changed answer fails it. 3 of the 4 recorded are shown.
Flat filtered
Request
{
"direction" : "broughtInBy",
"moduleFilter" : "deptree.foundation"
}
Response
{
"deduplicated" : [ {
"broughtInBy" : [ "deptree.middleware" ],
"module" : "deptree.foundation",
"version" : "1.0.0-0"
} ],
"direction" : "broughtInBy",
"meta" : {
"serverMs" : "<timing>"
},
"rootPackage" : "deptree.analytics",
"rootVersion" : "3.0.0-0",
"summary" : {
"totalEdges" : 1,
"uniqueModules" : 1
}
}
Flat dedup
Request
{
"format" : "flat"
}
Response
{
"deduplicated" : [ {
"broughtInBy" : [ "deptree.middleware" ],
"module" : "deptree.foundation",
"version" : "1.0.0-0"
}, {
"broughtInBy" : [ "deptree.analytics" ],
"module" : "deptree.middleware",
"version" : "2.0.0-0"
} ],
"direction" : "broughtInBy",
"meta" : {
"serverMs" : "<timing>"
},
"rootPackage" : "deptree.analytics",
"rootVersion" : "3.0.0-0",
"summary" : {
"totalEdges" : 2,
"uniqueModules" : 2
}
}
Nested filtered
Request
{
"moduleFilter" : "deptree.middleware"
}
Response
{
"direction" : "dependsOn",
"meta" : {
"serverMs" : "<timing>"
},
"rejectedVersions" : [ ],
"rootPackage" : "deptree.analytics",
"rootVersion" : "3.0.0-0",
"selections" : [ {
"candidates" : [ "3.0.0-0" ],
"module" : "deptree.analytics",
"rule" : "no conflict",
"selected" : "3.0.0-0"
}, {
"candidates" : [ "1.0.0-0" ],
"module" : "deptree.foundation",
"rule" : "no conflict",
"selected" : "1.0.0-0"
}, {
"candidates" : [ "2.0.0-0" ],
"module" : "deptree.middleware",
"rule" : "no conflict",
"selected" : "2.0.0-0"
} ],
...
Cut short here: 17 more lines. The whole recorded call.
See also
- Part of the investigate_build_failure workflow: Diagnose dependency-resolution or compilation failure: diagnostics → tree → cycles → fix → re-resolve.