Skip to content

--importers: 'No files import X' is stated for cases where the graph cannot know, and the explanation is Go-specific #138

Description

@JordanCoin

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:

$ codemap --importers analysis/contracts.go
⚠️  HUB FILE: analysis/contracts.go — imported by 16 files

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).
  • Longer term this is the concrete motivating case for compose primitives: 'codemap check <file>' should answer AND say whether to believe the answer #133: the command should return a trust verdict alongside the count, because the count alone cannot express "I am structurally unable to answer this."

Why it matters

--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.

Related: #133, #132, #136, #111, #137.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions