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
Two related output bugs on the same command. Both make a cannot-know read as a known-negative, which is the answer most likely to be acted on destructively.
1. Same-package files report "No files import X"
codemap's graph is file-to-file via import statements. Go files in the same package do not import each other, so codemap has no edges inside a package — a structural property, not a gap in the scan. It reports it as a finding anyway:
$ codemap --importers watch/events.go
No files import watch/events.go.
watch/events.go is used throughout package watch. The honest answer is "same-package references are not modeled, I cannot tell you." What it says instead is indistinguishable from a genuinely unimported file.
Verified the asymmetry — cross-package works correctly:
So the command is reliable across packages and silently unreliable within one, with no way for the caller to tell which answer they just got.
2. The explanatory note is printed on non-Go files
The note under that message reads:
Note: files in the same package never import each other (Go resolves
imports at package level), so only cross-package importers appear here.
It is emitted unconditionally. Observed verbatim on a TypeScript file:
$ codemap --importers src/types.ts # a NodeNext TS project
No files import src/types.ts.
Note: files in the same package never import each other (Go resolves
imports at package level), so only cross-package importers appear here.
and on a Rust file. Neither language has Go package semantics, and in the TypeScript case the real reason for the empty answer was #132 — a resolution bug the note actively misdirects away from.
Suggested fix
Scope the note to Go sources. For other languages either omit it or state the actual reason.
Distinguish "no importers found" from "importers not modeled for this file". For a Go file whose package contains other files, say so rather than reporting zero — something like not modeled: same-package references (N other files in package watch).
--importers is the blast-radius command — the one an agent runs before deleting, renaming, or changing a signature. A false "no importers" is acted on. Between this and #132/#136 there are now three distinct paths to a confident zero, none of which flag themselves.
Two related output bugs on the same command. Both make a cannot-know read as a known-negative, which is the answer most likely to be acted on destructively.
1. Same-package files report "No files import X"
codemap's graph is file-to-file via import statements. Go files in the same package do not import each other, so codemap has no edges inside a package — a structural property, not a gap in the scan. It reports it as a finding anyway:
watch/events.gois used throughoutpackage watch. The honest answer is "same-package references are not modeled, I cannot tell you." What it says instead is indistinguishable from a genuinely unimported file.Verified the asymmetry — cross-package works correctly:
So the command is reliable across packages and silently unreliable within one, with no way for the caller to tell which answer they just got.
2. The explanatory note is printed on non-Go files
The note under that message reads:
It is emitted unconditionally. Observed verbatim on a TypeScript file:
and on a Rust file. Neither language has Go package semantics, and in the TypeScript case the real reason for the empty answer was #132 — a resolution bug the note actively misdirects away from.
Suggested fix
not modeled: same-package references (N other files in package watch).Why it matters
--importersis the blast-radius command — the one an agent runs before deleting, renaming, or changing a signature. A false "no importers" is acted on. Between this and #132/#136 there are now three distinct paths to a confident zero, none of which flag themselves.Related: #133, #132, #136, #111, #137.