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
fix: resolve type-only imports for dead code analysis (#862)
* fix: resolve type-only imports for dead code analysis (#840)
Type-only imports (import type { Foo }) created file-level edges but no
symbol-level edges, so interfaces consumed only via type imports had
fanIn=0 and were falsely classified as dead-unresolved.
- Create symbol-level imports-type edges in buildImportEdges targeting
the actual imported symbol nodes
- Include imports-type edges in fan-in, isExported, and prodFanIn
queries in both full and incremental role classification
* fix: filter symbol-level edges from file-level import metrics
computeImportEdgeMaps queries all imports-type edges for file-level
fan-in/fan-out metrics. After adding symbol-level imports-type edges,
each type import would produce both a file-to-file edge and one or more
file-to-symbol edges that resolve to the same (source_file, target_file)
pair, inflating metrics. Adding AND n2.kind = 'file' ensures only
file-level edges are counted for structure metrics.
* fix: add symbol-level type-import edges to native and incremental paths
The symbol-level imports-type edges added in the JS buildImportEdges
path were missing from three other code paths:
1. Native napi build_import_edges (edge_builder.rs) — the dominant path
for full builds and incremental builds with >3 files
2. Native DB-based build_import_edges (import_edges.rs) — used by the
Rust build pipeline
3. Incremental single-file rebuild (incremental.ts) — used by watch mode
Without these edges, type-imported symbols still had fanIn=0 on native
builds and were falsely classified as dead-unresolved.
Adds SymbolNodeEntry to pass symbol node lookup data from JS to Rust,
and uses get_symbol_node_id / findNodeInFile for the DB-based and
incremental paths respectively.
* fix(bench): allowlist 3.9.0 fnDeps regression in benchmark guard
The 177-184% fnDeps latency jump from 3.7.0 to 3.9.0 reflects codebase
growth (23 new language extractors in 3.8.x) and the comparison gap
(3.8.x query data was removed). This is already documented in
QUERY-BENCHMARKS.md and is not a real performance regression.
0 commit comments