Typescript, deferred imports incorrectly detected as cycles

[bannable]

Versions tested: 0.8.35, 0.8.37

// modal.ts
import {hideModal} from './actions';

export function Modal(): void {
  hideModal();
}

// actions.ts
export function showModal(): void {
  void import('./modal').then((m) => m.Modal());
}

export function hideModal(): void {}

from graphify.analyze import find_import_cycles
from graphify.build import build_from_json
from graphify.extract import extract

def test_deferred_import_is_not_a_cycle():
    result = extract(
        ["modal.ts", "actions.ts"]
    )
    graph = build_from_json(result)
    cycles = find_import_cycles(graph)

    assert cycles == [], (
        "deferred import() was counted as a static import edge and reported "
        f"as a circular dependency: {cycles}"
    )

test_deferred_import_is_not_a_cycle()

I suspect this kind of pattern is what led to the cycling in #1196, so it might be worth keeping track of whether the import is deferred while computing cycles.

[Synvoya]

Confirmed the root cause on v8 @ 983da3c (v0.9.6).

The deferred import('./modal') edge is emitted by _dynamic_import_js in graphify/extract.py with "relation": "imports_from" — the same relation as a static import:

# graphify/extract.py:1932
edges.append({
    "source": caller_nid,
    "target": tgt_nid,
    "relation": "imports_from",   # <- indistinguishable from a static import
    "context": "import",
    ...
})

find_import_cycles in graphify/analyze.py:663 then counts it as a cycle edge:

if rel not in ("imports_from", "re_exports"):
    continue

So modal.ts →(static) actions.ts plus actions.ts →(deferred) modal.ts collapse into the 2-file cycle you're seeing — a deferred import() is exactly the case where the two files shouldn't be treated as a hard cycle.

There's already a precedent for the fix in the codebase. The Svelte, Astro, and Vue extractors emit dynamic imports with a distinct relation, "dynamic_import" (e.g. extract.py:5813, 5824, 5933), and that relation is deliberately not in SEMANTIC_RELATIONS (extract.py:97) and not consulted by find_import_cycles — so those deferred imports never manufacture a cycle. _dynamic_import_js (the plain .js/.jsx/.ts/.tsx path) is the one dynamic-import emitter still using imports_from.

Changing extract.py:1935 from "imports_from" to "dynamic_import" lines it up with the sibling extractors: the edge stays in the graph (the deferred dependency is still visible to agents), but — since find_import_cycles only walks imports_from/re_exports — it no longer counts toward cycle detection, so the phantom cycle disappears. Happy to open a PR with that change plus a regression test.

[Synvoya]

Quick correction to my note above, from digging in while preparing the fix.

The straight retag of the deferred edge to dynamic_import doesn't actually keep it in the graph. Because the edge's source is a symbol node (the enclosing function) and its target isn't a materialized file node, the valid-id prune passes (extract.py:5380 and its siblings) only spare the edge while its relation is imports_from / re_exports. Retagging drops it entirely — so the deferred dependency would be lost, not just made cycle-exempt.

PR #1679 takes a cleaner route: keep the edge as imports_from (the dependency stays visible) and mark it deferred, then skip deferred edges in find_import_cycles. Verified end-to-end — the two-file repro returns no cycle, the deferred edge is still present, and the full test_js_import_resolution.py + test_analyze.py suites pass (negative control: reverting the change fails the new test).