Repository navigation
PHP: every use Namespace\* resolves to the same file #1186
Description
Opened the graph UI on a Laravel + Flutter repo and one file showed up as a massive hub, with most of the codebase apparently importing it. It's a small model class in a corner feature. Four files actually use it. The graph had 924 incoming IMPORTS.
Every use App\Models\* in the project resolves to that one file. Checking local_name on the incoming edges makes it obvious:
User 193
Agency 114
Property 83
Client 77
Agent 69
None of those are the class the node belongs to. It's the entire namespace collapsed onto whichever file the indexer reached first — not alphabetically first, I checked that.
Same in my other two PHP namespaces: 147 edges where 3 are real, and 56 where 1 is real.
That's 31% of every IMPORTS edge in the project sitting on one node, so import fan-in is meaningless for PHP. It's worse in the UI than in queries, because a fabricated hub looks exactly like a genuine one.
Possibly the same root cause: 451 CALLS edges connect files in different languages. PHP→Dart 250, PHP→JS 147, Dart→PHP 54. No FFI or codegen involved, these can't exist. They're all generic callee names — validated, filter, get, load — matched on bare name against the whole index. Same reason one policy method ends up with 587 incoming calls: that's every Eloquent ->create() in the repo landing on it.
451/6385 is a floor on the CALLS error rate, since it only counts what's provable by language mismatch.
confidence does rescue CALLS, unlike IMPORTS. I spot-checked 17 edges at >= 0.9 against the source and all 17 were right, with correct line numbers. The junk is all down at 0.09–0.38. The catch is that the useful cross-file PHP calls are at 0.38 as well, mixed roughly half and half with fabrications, so there's no threshold that keeps controller→service edges and drops the invented ones. At >= 0.9 PHP is just intra-file $this-> calls. JS resolution is solid though, 8/8 correct at 0.95 via import_map.
For the unresolved case I'd much rather get no edge than a confident wrong one. And refusing to resolve calls across language boundaries would drop those 451 for free.
0.9.0, linux x86-64, indexed with mode: full. ~1050 source files, 11003 nodes / 29896 edges. Happy to run queries against this index if it helps.
Activity
[-]PHP: every `use Namespace\*` import collapses onto one arbitrary file — 31% of IMPORTS edges land on a single node[/-][+]PHP: every `use Namespace\*` resolves to the same file[/+]DeusData commentedon Jul 22, 2026
Thanks for quantifying both the fabricated PHP IMPORTS hub and the provably impossible cross-language CALLS edges. This is a high-priority
0.9.1-rcgraph-correctness bug under #594. The acceptance bar is fail-closed resolution: wildcard imports must resolve per symbol rather than per namespace bucket, and generic bare-name fallback must not cross unrelated language registries. No additional reporter action is needed right now.DeusData commentedon Sep 26, 2026
Thank you, @softronicve, for quantifying this so carefully! We reproduced the IMPORTS collapse on current main. With PSR-4 autoloading,
use App\Models\Agency;still resolves toUser.php, the first file in the namespace directory. That keeps this open as a real graph-correctness bug. The cross-language CALLS half, where a name-only match binds a call to another language's symbol, is being worked on separately.fix(pipeline): resolve PSR-4 imports to exact class files
fix(pipeline): scope the psr-4 unresolved short-circuit to PHP importers
fix(routes): leave a PSR-4-covered handler without a class file unres…
fix(pipeline): restrict PHP imports to matching project namespaces
fix(php): keep proven vendor types out of project name fallbacks
fix(php-lsp): resolve grouped use declarations like the extractor
fix(pipeline): keep one record per superseded LSP occurrence
fix(php): classify proven vendor calls by their vendor class
test(parallel): correct two #1186 vendor fixture assertions
fix(pipeline): give sequential service edges the parallel args shape
test(parallel): compare #1186 service edges whole again
fix(php): keep proven vendor types out of project name fallbacks
fix(php-lsp): resolve grouped use declarations like the extractor
fix(pipeline): keep one record per superseded LSP occurrence
fix(php): classify proven vendor calls by their vendor class
test(parallel): correct two #1186 vendor fixture assertions
fix(pipeline): give sequential service edges the parallel args shape
test(parallel): compare #1186 service edges whole again
DeusData commentedon Oct 19, 2026
Thank you for the quantified PHP import and call-edge examples. The last reproduction still showed the PSR-4 IMPORTS collapse; I have no new resolution to report. The cross-language CALLS case remains distinct, so improvement there should not be taken as confirmation that the import issue is fixed.