JS/TS: a .js import specifier never resolves to a .tsx file, dropping every NodeNext-style import of a TSX module

[cbartens]

Summary

_resolve_js_import_path maps a .js import specifier to .ts and stops. TypeScript's documented resolution order for a .js specifier is .ts → .tsx → .d.ts → .js, so every NodeNext/Node16-style import of a .tsx file is dropped from the graph.

On a 1,430-file TypeScript monorepo this loses 171 import edges, and presents as .tsx files appearing unreachable.

Where

graphify/extractors/resolution.py (branch v8, 0.9.58 — also 0.9.50):

# TS ESM convention: imports often spell .js/.jsx while source is .ts/.tsx.
if candidate.suffix == ".js":
    ts_candidate = candidate.with_suffix(".ts")
    if ts_candidate.is_file():
        return ts_candidate
elif candidate.suffix == ".jsx":
    tsx_candidate = candidate.with_suffix(".tsx")
    if tsx_candidate.is_file():
        return tsx_candidate

The comment names the right convention, but .js only ever tries .ts. A .tsx source file is imported as .js, not .jsx — TypeScript emits Foo.tsx to Foo.js, so the specifier the compiler requires is ./Foo.js. ./Foo.jsx is only correct under jsx: preserve, which is the rarer case.

The append-extension loop underneath does not rescue it, because it appends to the full filename rather than replacing the suffix:

for ext in _JS_RESOLVE_EXTS:
    with_ext = candidate.parent / f"{candidate.name}{ext}"   # MessageBubble.js.tsx

Reproduction

src/Button.tsx          export function Button() {}
src/App.ts              import { Button } from "./Button.js";

with "moduleResolution": "nodenext". Expected: an import edge App.ts → Button.tsx. Actual: none — Button.tsx has zero inbound edges.

Directly against the resolver:

>>> from graphify.extractors.resolution import _resolve_js_import_path as R
>>> from pathlib import Path
>>> R(Path("src/Button.js"))       # Button.tsx exists on disk
PosixPath('src/Button.js')          # unresolved
>>> R(Path("src/helper.js"))       # helper.ts exists on disk
PosixPath('src/helper.ts')          # fine

Measured impact

Real monorepo, 1,430 source files, 10,958 nodes / 19,266 edges:

Relative .js specifiers	Count
resolve to .ts	1,041
resolve to .tsx — edge lost	171

The asymmetry is visible in the graph as a large difference in apparent reachability between two extensions under one import convention:

Non-test source	Files	Zero inbound	Rate
.ts	472	47	10%
.tsx	185	82	44%

After repairing only this one case out-of-band, .tsx drops to 15% and 54 files stop reading as unreachable.

This matters beyond edge counts: it makes affected, any dead-code pass, and any reachability question quietly wrong for .tsx files, in the direction that is hardest to notice — a missing edge looks like a clean result.

Suggested fix

Replace the branch with a suffix→candidates table, preserving the existing order semantics:

_TS_OUTPUT_EQUIVALENT = {
    ".js":  (".ts", ".tsx", ".d.ts"),
    ".jsx": (".tsx",),
    ".mjs": (".mts", ".d.mts"),
    ".cjs": (".cts", ".d.cts"),
}

for replacement in _TS_OUTPUT_EQUIVALENT.get(candidate.suffix, ()):
    sibling = candidate.with_suffix("")  # .with_suffix(".d.ts") mangles the stem
    rewritten = sibling.parent / f"{sibling.name}{replacement}"
    if rewritten.is_file():
        return rewritten

Note Path.with_suffix(".d.ts") does not do what it looks like it does on a multi-dot stem, hence building the name by concatenation.

.mjs/.cjs are included for completeness; I have no repro for those, only for .js → .tsx.

Happy to open a PR with this plus a test if that is useful.

[cbartens]

Workaround for anyone hitting this before it lands upstream

Posting what we run, since both this and the sibling issue bite the same repos and the fix is the same shape either way.

We do not patch the installed package — uv tool upgrade silently reverts it, and a workaround that disappears on upgrade is worse than none. Instead we re-derive the missing edges from source and inject them into graph.json as a build step.

Where it goes in the pipeline

graphify extract . --code-only
  └─ graph-repair.py graph.json      <-- inject here
graphify cluster-only . --no-label --no-viz

Before cluster-only, deliberately. Communities, the god-node ranking and the cycle list in GRAPH_REPORT.md are then all computed from the repaired graph rather than one missing a sixth of its imports.

What gets written

One imports_from link per recovered file pair, between the two files' L1 nodes — the shape graphify already uses for a file-to-file dependency:

{"source": file_node[src], "target": file_node[dst],
 "relation": "imports_from", "_origin": "graph-repair",
 "confidence": "EXTRACTED", "confidence_score": 1.0,
 "context": "import", "source_file": src, "source_location": "L1", "weight": 1.0}

The _origin tag matters: injected edges stay greppable and never pass as graphify's own extraction.

Result — graphify explain sees an edge it could not resolve itself:

$ graphify explain "sign-in-magic-link.tsx"
Connections (3):
  <-- auth/actions.ts [imports_from] [EXTRACTED]  packages/services/src/auth/actions.ts:L1

Four things that cost us a debugging cycle each

1. A top-level marker does not survive. Setting graph["import_repair"] = {...} is dropped by cluster-only, which keeps only keys it writes itself — built_at_commit survives because graphify sets it, a custom key does not. Per-link attributes do survive, so detection has to be "are there links with my _origin", not a header field.

2. Strip your previous injection BEFORE computing what already exists. Otherwise run two sees last run's edges, treats every candidate as already present, skips them all, then deletes them — leaving the graph worse than unrepaired, and only ever on the second run. Order:

links = [l for l in links if l.get("_origin") != ORIGIN]   # strip first
existing = {(path(l["source"]), path(l["target"])) for l in links if ...}

3. graphify update rewrites graph.json and drops the injection. So the step has to run on every command that writes the file, not once by hand. Ours is wired into the build / clean / update wrapper and is idempotent, so re-running recovers.

4. Do not also repair on read. We first had our downstream consumers re-derive the same edges when loading graph.json. Once the file itself was repaired that double-counted every pair graphify had partially resolved, and inflated our package-level edge weights by 10-20%. Repair in one place; have readers warn if the marker is missing rather than silently re-deriving.

Scope

The resolver handles relative specifiers (./Foo.js → Foo.ts / Foo.tsx / Foo.d.ts, plus Foo.native.tsx / Foo.web.tsx for bundler platform splits) and workspace subpaths through exports maps, choosing the export condition by the importing file's platform. ~540 edges on a 1,430-file monorepo.

Happy to contribute the resolution logic as a PR against _resolve_js_import_path if that is wanted — it is the same matching, just inside graphify instead of bolted on after.