You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Dart extension members are missing from the graph #1457
The Dart extractor does not descend into extension X on Y { } bodies. Every method declared inside an extension is absent from the graph.
Repro
One file, lib/a.dart:
classHolder {
finalint value;
constHolder(this.value);
}
extensionHolderMathonHolder {
intdoubled() => value + value;
inttripled() => value + value + value;
StringdescribeHolder() =>'holder';
}
inttopLevelHelper(int x) => x +1;
Run index_repository, then search_graph for doubled, tripled, describeHolder, or HolderMath. Nothing matches. Holder, value, and topLevelHelper are all indexed.
Version
Reproduced on 0.8.1 and on 0.9.0. 0.9.0 emits one extra node for the same file, a Folder bookkeeping node, not the extension.
Impact
Dart codebases that use part of plus extensions to split a large class are almost entirely invisible. In our function, 24 of 57 files under lib/src are extension bodies, roughly 266 methods with no nodes. Tools built on top of the graph silently see an empty result instead of an error.
Workaround
search_code still finds these files because it greps raw content, so anything gated on graph coverage can fall back to the file key it returns.
Thank you so much @sgaabdu4 for this report. The minimal repro, the version check across 0.8.1 and 0.9.0, and the impact numbers made it quick to pin down.
You were right: the Dart extractor didn't know extension_declaration was a container, so neither the extension nor anything inside it reached the graph. #2321 registers extensions as containers: extension HolderMath on Holder { ... } now shows up as a node with doubled, tripled and describeHolder as methods under it, and calls between them are attributed correctly. Members of unnamed extension on T { ... } blocks are indexed as file-level functions. On your repro the file goes from 4 to 9 nodes, so your 24 extension files under lib/src should show up after upgrading and re-indexing. Thanks again!
Activity
DeusData commentedon Sep 25, 2026
Thank you so much @sgaabdu4 for this report. The minimal repro, the version check across 0.8.1 and 0.9.0, and the impact numbers made it quick to pin down.
You were right: the Dart extractor didn't know
extension_declarationwas a container, so neither the extension nor anything inside it reached the graph. #2321 registers extensions as containers:extension HolderMath on Holder { ... }now shows up as a node withdoubled,tripledanddescribeHolderas methods under it, and calls between them are attributed correctly. Members of unnamedextension on T { ... }blocks are indexed as file-level functions. On your repro the file goes from 4 to 9 nodes, so your 24 extension files underlib/srcshould show up after upgrading and re-indexing. Thanks again!Merge pull request #2321 from DeusData/fix/issue-1457
fix(dart): index extension declarations and their members (DeusData#1457
DeusData commentedon Sep 30, 2026
Thank you again for reporting this, @sgaabdu4! The fix is now on
mainin f5ecb5f (merged via #2321), and it will ship in the next release.