fix(resolution): an import naming the emitted .js extension resolves to its .ts source

[bompus]

Fixes #1705.

What

resolveRelativeImport and the aliased path's tryWithExt now fall back to findSourceForEmittedSpecifier: when a specifier ends in .js / .jsx / .mjs / .cjs and no file of that exact name exists, the source extensions TypeScript compiles from are tried (.ts, .tsx, .d.ts / .tsx / .mts, .d.mts / .cts, .d.cts). Only for the TS/JS-family languages (typescript, tsx, javascript, jsx, vue, svelte, astro, arkts); a real .js beside the .ts still wins because the existing as-is check runs first.

Why

Under moduleResolution: node16 | nodenext | bundler the emitted extension is what TypeScript requires in the specifier, so every import in such a project was invisible to the import resolver and each imported name fell through to bare-name matching. The clearest symptom is a method that wraps the same-named function it imports resolving to itself (a calls self-edge at confidence 0.4); the wider one is that cross-module edges in these projects were name guesses instead of import-backed.

Measured

Real repo, 582 files, 92 .ts files with .js specifiers, indexed with and without this change on the same build:

	before	after
calls/imports edges resolvedBy: import	4,002	7,312
… resolvedBy: exact-match	15,419	12,784
… resolvedBy: fuzzy	44	23
self-calls edges	31	22 (the 8 wrapper-method ones gone; the rest are recursion)

Tests

__tests__/import-emitted-specifier.test.ts: unit cases through resolveImportPath for .js, .jsx, .mjs, .cjs, the real-.js-wins case, an aliased @/lib/util.js, a missing target, and a non-TS language; plus an end-to-end CodeGraph.init on the wrapper-method repro asserting the edge lands on the imported function and not on the method. Full suite: no failure outside the host's known EPERM/EBUSY teardown set.

[bompus]

Real-repo check: one edge gained, zero lost

Ran this against vitejs/vite (1,635 files, 9,354 nodes, 27,499 edges) — index the same checkout with each build, then diff the full edge set joined back to symbol names and call-site lines. Indexing is deterministic, so the diff is this change and nothing else.

27,499 → 27,500 edges. One gained, none lost. The one:

imports  playground/resolve/ts-extension/index-js.js@1  ->  hello.ts:msg

which is the fixture line import { msg as msgJs } from './hello.js', resolving to hello.ts — the exact case in the title.

What I found interesting is the shape of the gap. That fixture imports five sibling modules through their emitted extension, and main already resolved four of them:

line	import	on main	with this PR
1	'./hello.js' → hello.ts	unresolved	resolved
2	'./hellocjs.cjs' → hellocjs.cts	resolved	resolved
3	'./hellojsx.jsx' → hellojsx.tsx	resolved	resolved
4	'./hellomjs.mjs' → hellomjs.mts	resolved	resolved
5	'./hellotsx.js' → hellotsx.tsx	resolved	resolved

So the only broken variant was the plainest and by far the most common one — .js → .ts — while .cjs/.mjs/.jsx all worked. That's a good sign the change is aimed at the right hole, and the zero-loss column says it doesn't widen anything else: across 27,499 edges nothing was dropped or re-pointed.

One caveat on scope. This checkout has no kernel binary staged, so extraction ran the wasm path in both arms. Resolution is shared TS and sits downstream of extraction, so the result holds either way, but I have not re-run it against a kernel-extracted graph.