Detector::Go::Cli
Detects Go command-line applications: programs that parse argv / flags
through the stdlib flag package or a CLI framework (cobra, urfave/cli,
go-arg, go-flags, pflag, kong, kingpin, mitchellh/cli), or that index
os.Args directly. Gates the Go CLI analyzer, which surfaces the argv /
flag / env attack surface as cli:// endpoints.
Constants
Direct argv indexing, e.g. os.Args[1].
A real call into the stdlib flag package (not just the bare token
"flag", which appears in unrelated identifiers/comments).
Single-pass union of the library markers above. The any? includes?
chain walked every non-CLI .go file nine times over.
CLI framework import paths. Presence of any of these — in go.mod or a source import block — is a strong, unambiguous CLI signal.
The stdlib flag import line.
An HTTP listener: a file that uses the stdlib flag package for config
AND serves HTTP is a web server, not a CLI, so the stdlib signals below
don't qualify it (a real CLI framework, matched earlier, still does).
Class methods
The tech name without needing an instance, so the registry can be read off the classes themselves rather than from a parallel list.
Instance methods
Cheap filename-only filter the detector pass uses to skip
detect on files the detector cannot possibly match. The
default true preserves prior behavior (every detector runs on
every file). Override with the same predicate the body of
detect starts with — e.g., filename.ends_with?(".py") for a
Python framework detector — so the detector loop avoids the
detect dispatch on files outside the detector's language.
On large codebases (saleor's 4255 .py files) this lifts ~100
virtual detect calls per file out of the hot loop because
most detectors' inner first-line is exactly this kind of cheap
filename check.