fix(scanner): Resolve TypeScript ESM specifiers that name emitted files

[JordanCoin]

Last of the Graph accuracy milestone (#172). Fixes #132.

✅ Now based on main. #171 has merged (49f9ed6), so main is brought in and the diff is this PR's own 12 files: scanner/filegraph.go, scanner/tsesm_test.go, testdata/typescript-esm-specifiers/.

What was wrong

Under ESM and NodeNext, TypeScript requires the specifier to name the emitted file. So a project's own source reads:

import { helper } from "./helper.js";   // the only file on disk is helper.ts

The specifier already carries an extension, so tryExactMatch appending resolver extensions produced helper.js.ts and matched nothing. Every such import was lost — and since NodeNext makes this mandatory rather than stylistic, that's most imports in an affected project.

The fix, and the case it must not break

An emitted extension now maps back to the TypeScript sources that produce it — but only after the literal path has been tried. That ordering is the important part:

src/real.js  importers = [src/c_real_js_wins.ts]     <- an existing .js wins
src/real.ts  importers = []                          <- its .ts twin does not steal the edge

If helper.js genuinely exists beside helper.ts, the specifier names a file that exists, and rewriting it to TypeScript would be a wrong edge rather than a missing one. The fixture has exactly that pair to pin it.

main's tryExactMatch (post-#171) checks the literal path first, then loops the resolver extensions; the new candidate loop sits between the two, so the ordering guarantee is structural rather than incidental.

The fixture

testdata/typescript-esm-specifiers/, a NodeNext tsconfig.json and:

src/helper.ts    importers = [a_js_to_ts.ts, d_extensionless.ts]   ./helper.js and ./helper
src/widget.tsx   importers = [b_jsx_to_tsx.ts]                     ./widget.jsx
src/real.js      importers = [c_real_js_wins.ts]                   real .js wins
src/real.ts      importers = []
src/e_missing.ts imports   = []                                    ./absent.js resolves to nothing

Against the base, TestTypeScriptESMSpecifiersResolve fails with src/helper.ts importers = [src/d_extensionless.ts], want [src/a_js_to_ts.ts src/d_extensionless.ts] and src/widget.tsx importers = [].

What I deliberately did not claim

.mjs and .cjs are unmapped. They emit from .mts and .cts, which aren't recognized source extensions here — the scanner never indexes such a file, so a mapping for them would be unreachable code that reads like support. I had both in the first draft and removed them once I checked extToLang. Adding .mts/.cts as scanned extensions is a separate change with its own file-count consequences; the tests pin the current behaviour (mjs has no reachable counterpart) so it's visible rather than silently missing.

Per-ecosystem summary (for release notes)

Ecosystem	Before	After
TypeScript ESM / NodeNext (./x.js → x.ts, ./x.jsx → x.tsx)	resolved to nothing; most imports lost	resolved, including .d.ts
A real .js beside a same-named .ts	resolved to the .js	unchanged — still the .js
.mjs / .cjs specifiers	unresolved	unresolved (.mts/.cts are not scanned)
Every other ecosystem	unchanged	unchanged

Verification (on the merge, at 0695c28)

go build ./... OK, go vet ./... clean, gofmt clean. TestTypeScriptESMSpecifiersResolve and TestTypeScriptESMMissingSpecifierResolvesToNothing both pass. go test ./... at the repository baseline — only the three known root-environment permission failures (TestRunSetupCreatesConfigAndHooks, TestSelectReportsInaccessiblePrimarySetup, TestListProjectsPreservesPerChildScanErrors).

The merge of main had one conflict, in tryExactMatch: an add-on-one-side conflict where this PR contributes the candidate loop and main contributes nothing. Resolved by keeping the block, positioned after the literal check and before the extension loop — verified by reading the resulting function and by the real.js / real.ts fixture pair, which is precisely the assertion that fails if the ordering is wrong.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PEUvjGsJemDFSV8nbxvxBo

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[JordanCoin]

Correction to this PR's rebase note: the rebase onto main is not mechanical

I wrote above that I'd "rebase once #171 lands and the diff will shrink to the four files below." I tested that claim rather than leaving it as an assumption, and it is wrong in a way that matters: a naive rebase of this change onto main fabricates a wrong edge.

Why

The two branches order tryExactMatch differently.

main (c02e15a) tries the bare path last — ResolverExtensions() ends with exts = append(exts, ""), described in its own doc comment as "empty string last as the final fallback":

extensions := ResolverExtensions()
for _, ext := range extensions {      // "" is the LAST element

#171 tries the literal path first, then loops the extensions with the trailing "" dropped:

if idx.byExact[path] == 1 && languagesCompatible(...) { return []string{path} }
for _, ext := range resolverExtensions[:len(resolverExtensions)-1] {

This PR's fix inserts typescriptSourceCandidates after the literal check, which on #171 is correct. Carried onto main with the same hunk shape, the candidates land before the literal path is ever tried — so ./real.js matches real.ts while real.js is sitting on disk beside it.

Reproduced, not argued

Cherry-picking 364966f onto c02e15a conflicts in scanner/filegraph.go. Resolving it the obvious way (keep main's loop, insert the candidate loop above it) builds clean and then fails this PR's own fixture:

tsesm_test.go:37: src/real.js importers = [], want exactly [src/c_real_js_wins.ts]
                  (an existing .js beats the .ts counterpart)
tsesm_test.go:37: src/real.ts importers = [src/c_real_js_wins.ts], want exactly []
                  (the .ts counterpart must not steal the edge)

That is a wrong edge, not a missing one — the failure mode this repo treats as the cardinal sin, and precisely what c_real_js_wins.ts was added to catch. The fixture does its job; I'm flagging it because the PR body currently invites the exact resolution that trips it.

The safe main-shaped resolution

main needs an explicit literal-path check ahead of the candidates, using its own []string / compatibleFiles index shape:

// main orders the bare-path match LAST (ResolverExtensions ends in ""),
// so the literal path has to be tried explicitly before rewriting a
// specifier to its TypeScript source. Otherwise "./real.js" matches
// real.ts while real.js sits on disk beside it -- a wrong edge, not a
// missing one.
if files, ok := idx.byExact[path]; ok {
    if compatible := compatibleFiles(sourceLanguage, files); len(compatible) > 0 {
        return compatible
    }
}

for _, candidate := range typescriptSourceCandidates(path, sourceLanguage) {
    if files, ok := idx.byExact[candidate]; ok {
        if compatible := compatibleFiles(sourceLanguage, files); len(compatible) > 0 {
            return compatible
        }
    }
}

With that, on main at c02e15a: TestTypeScriptESMSpecifiersResolve passes, go vet ./... is clean, go test ./scanner/ is green, and go test ./... is at the known baseline (the three root-environment permission failures only).

What I'm not doing

Not re-cutting this PR yet — the standing decision was to build on #171 and rebase after it lands, and I'm not overriding that on my own. This is here so that whoever performs the rebase (me, later, or anyone else) knows it needs the literal-path check added rather than a straight conflict resolution, and has a verified version to use.

Note this cuts both ways: #181 cherry-picks onto main cleanly, but this one does not, so "both were verified to merge cleanly" — which is true of a git merge of main into these branches — should not be read as "both rebase safely." A clean merge here still carries #171's commits, which is what makes it clean.

---

Generated by Claude Code

[JordanCoin]

Resolved — and my earlier hazard comment no longer applies

My comment above warned that rebasing this PR onto main would fabricate a wrong edge, and gave a main-shaped remedy. That remedy is now unnecessary, and following it would be wrong. Recording that explicitly so nobody applies a fix to a problem that no longer exists.

The hazard was entirely about an ordering difference between the two bases:

• main at the time tried the bare path last (ResolverExtensions() ended in "")
• perf: Bound repository analysis hot paths #171 tried the literal path first

#171 has since merged as 49f9ed6, so main now has the literal-path-first ordering this PR was written against. The two bases converged, and the conflict that produced the wrong edge is gone with them.

What I actually did

Merged main into this branch — no rebase, no force-push, so the existing history and any in-flight review stay valid. One conflict, in tryExactMatch, and it was the benign kind: this PR contributes the candidate loop, main contributes nothing at that spot. Kept the block, positioned after the literal check and before the extension loop:

if idx.byExact[path] == 1 && languagesCompatible(sourceLanguage, DetectLanguage(path)) {
    return []string{path}
}
// Under ESM and NodeNext, TypeScript requires the specifier to name the
// emitted JavaScript file, ...
for _, candidate := range typescriptSourceCandidates(path, sourceLanguage) {
    ...
}
for _, ext := range resolverExtensions[:len(resolverExtensions)-1] {

I didn't take "one trivial conflict" as sufficient reason to trust it — the whole point of the earlier finding was that a plausible-looking resolution here silently produces a wrong edge. So the check is the fixture, not the diff: src/real.js and src/real.ts exist side by side specifically so that any resolution which lets the .ts steal the edge fails loudly. It passes.

At 0695c28: diff is this PR's own 12 files, go build OK, go vet clean, gofmt clean, both TypeScript ESM tests pass, go test ./... at the repository baseline (the three known root-environment permission failures only).

This is the last of the Graph accuracy milestone (#172) — #148, #173, #147 and #136 are all on main.

---

Generated by Claude Code

[reneleonhardt]

After all those substantial PRs I didn't expect a patch release 😄

Can your Claude double-check all of README, everything up-to-date?