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
Independent reviews of #181 and #182 (2026-09-04) both hit the same thing: when a TypeScript, JavaScript, or Python import cannot be resolved to a file, the edge is dropped and nothing in --deps, --importers, or the JSON coverage block says so. Only Rust emits a note (rustCoverageNote in scanner/rustgraph.go).
Python: an over-climbing relative import or an unmatched relative target resolves to nothing with coverage_status: complete.
.cjs is absent from the extension map (scanner/types.go:182-184), so CommonJS .cjs files are invisible with no disclosure.
Why it matters
The README promise is "tells you when it doesn't know." #174 made that true for symbol-level languages; #180's collide verdict and the hosted collision report both key off coverage_status. A file-level language that silently drops edges still reports complete, so a consumer cannot tell a checked-and-empty answer from an unchecked one.
Proposed fix
Count unresolved local-looking specifiers per language during graph build (relative paths, alias-matched paths, and .js/.mjs/.cjs/.jsx specifiers that matched no file) and, when the count is non-zero, append a partial source naming the language and count, following the Rust pattern. Third-party package specifiers are not "unresolved" and must not trigger it. Fixture per language; a test that the note appears for the .mts case and does not appear for a clean project.
Symptom
Independent reviews of #181 and #182 (2026-09-04) both hit the same thing: when a TypeScript, JavaScript, or Python import cannot be resolved to a file, the edge is dropped and nothing in
--deps,--importers, or the JSON coverage block says so. Only Rust emits a note (rustCoverageNotein scanner/rustgraph.go).Reproductions from the reviews:
.mjs->.mtsand.cjs->.ctsspecifiers (not covered by fix(scanner): Resolve TypeScript ESM specifiers that name emitted files #182):--depsprints "5 files · 5 functions · 0 deps" with no note.coverage_status: complete..cjsis absent from the extension map (scanner/types.go:182-184), so CommonJS.cjsfiles are invisible with no disclosure.Why it matters
The README promise is "tells you when it doesn't know." #174 made that true for symbol-level languages; #180's collide verdict and the hosted collision report both key off
coverage_status. A file-level language that silently drops edges still reportscomplete, so a consumer cannot tell a checked-and-empty answer from an unchecked one.Proposed fix
Count unresolved local-looking specifiers per language during graph build (relative paths, alias-matched paths, and
.js/.mjs/.cjs/.jsxspecifiers that matched no file) and, when the count is non-zero, append apartialsource naming the language and count, following the Rust pattern. Third-party package specifiers are not "unresolved" and must not trigger it. Fixture per language; a test that the note appears for the.mtscase and does not appear for a clean project.Related: #148, #174, #181, #182, #172.
🤖 Generated with Claude Code
https://claude.ai/code/session_01TcyheQmM3HCvxF5wRL3s5t