goda dependency analysis for Go binary-size reduction

Why goda targets Go dependency inspection

goda addresses a specific problem: understanding what a Go program imports, which dependencies are reachable, and which code contributes to a compiled binary. The README positions it for dependency analysis and binary-size reduction, which makes it relevant to maintainers of command-line tools, applications with large dependency graphs, and developers investigating changes in build output. It is not a general-purpose Go build system or a replacement for package compilation.

The repository layout points to a Go command implemented through `main.go`, with the main analysis packages under `internal/`. Its dependencies include `golang.org/x/tools`, `golang.org/x/mod`, and `github.com/google/subcommands`, while the module declares `go 1.26.0`. The README says the toolkit is designed around Go's package and module information, but it does not document a compatibility matrix for older Go releases. The declared toolchain requirement is therefore the clearest installation constraint available from the repository.

Package expressions and set-based queries

The central interface is a package expression language rather than a collection of narrowly named flags. A basic query can name multiple packages. The suffix `:import` selects direct dependencies, `:import:all` selects direct and indirect dependencies, and `:all` selects the package plus its direct and indirect dependencies. This lets a query define a dependency set before a command consumes it.

The expressions also support arithmetic. The README gives subtraction as a way to exclude `golang.org/x/tools/...` from a larger dependency set. Other documented forms include `shared(...)`, `reach(...)`, `purego=1(...)`, `goos=windows(...)`, and `goos=linux(...)`. The README also documents `deadcode(...)` for finding packages that may prevent dead-code elimination, including cases associated with `reflect.Value.MethodByName`.

This syntax is useful for investigations that would otherwise require separate queries and manual filtering. It is also a limitation for users who prefer stable, conventional command-line interfaces. The README explicitly warns that the exact syntax of command-line arguments has not been finalized and that changes should be expected. Scripts and CI jobs that embed goda expressions should therefore treat the expression grammar as something to review during upgrades.

Install goda and generate a first dependency graph

The README directs users to install goda with Go's `go install` command. The command installs the repository's current version, and the documentation notes that `GOBIN` must be reachable on the command path. For graph output, the README additionally requires Graphviz for rendering. The following is the documented installation step:

go install github.com/loov/goda@latest

The README's graph examples run inside a cloned repository because the package patterns reference the goda module itself. The initial setup is therefore:

git clone https://github.com/loov/goda && cd goda

From that directory, the documented package graph query writes Graphviz input to standard output. The `dot` process converts that input into `graph.svg`:

goda graph "github.com/loov/goda:mod" | dot -Tsvg -o graph.svg

The `goda` command produces graph data, while `dot` performs SVG rendering. A reader without Graphviz installed can inspect the command output, but cannot complete the documented SVG conversion step.

List direct dependencies and compare platform sets

The `list` command is a practical first use for inspecting a module without opening a graph viewer. The README gives direct dependency queries for the goda module and for selected package patterns:

goda list "github.com/loov/goda/...:import"

The same query can target a local pattern, such as all packages below the current module. The repository examples use quoted patterns because the expressions contain characters that are meaningful to the shell or to goda.

Goda can compare shared package sets. For two internal package groups, the documented expression is:

goda list "shared(github.com/loov/goda/internal/pkgset:all, github.com/loov/goda/internal/cut:all)"

It can also identify dependencies introduced by a build tag or operating-system constraint. The following query lists packages imported with the `purego` tag:

goda list -std "purego=1(github.com/loov/goda/...:all)"

For platform-specific comparison, the README subtracts Linux dependencies from Windows dependencies:

goda list "goos=windows(github.com/loov/goda/...:all) - goos=linux(github.com/loov/goda/...:all)"

These queries are more specialized than a plain package listing. They can help explain why a build graph differs across constraints, but the README does not state whether every expression has identical semantics across commands or how errors are reported for an invalid package pattern. That behavior should be checked in the target repository before relying on automation.

Binary weight and dead-code investigation

goda's binary-oriented commands address dependency graphs after the compiler has produced a binary. The `weight` command sums symbol sizes per package, making it possible to see which packages occupy the most space in a final executable. The README gives this invocation:

goda weight -h $GOPATH/bin/goda

The `-h` option is documented in the example, but the repository does not provide a separate flag reference explaining its full behavior. The path is supplied through `$GOPATH/bin/goda`, so the command assumes that the binary exists at that location and that the user's environment is configured accordingly.

For comparing multiple versions, goda provides `weight-diff`:

goda weight-diff <1> <2> <3>

The README presents this as a way to investigate why binary size changed, but it does not specify the meaning of the three positional arguments beyond showing the command shape. Users should consult the command's own help output before building a release script around it.

The `cut` command presents a different perspective. It is intended to find packages with few dependents but a large size impact, which can identify candidates for removal. This is a prioritization aid, not a guarantee that deleting a package will be safe. Dependency reachability, runtime reflection, build tags, and linker behavior can make a package necessary despite a small number of visible dependents.

goda compared with go list and go mod

The README distinguishes goda from `go list` and `go mod` by scope. `go list` and `go mod` are integrated with the Go toolchain and are well suited to simple package and module queries. They can also serve as building blocks for other tools. goda instead targets more complicated dependency analysis, including set expressions, reachability, shared-package comparisons, build-tag filtering, graph output, and binary symbol weighting.

This difference does not make goda a substitute for the standard commands. The README explicitly says goda can be used alongside `go list` and `go mod`, which is the more accurate adoption model. Start with the standard tool when a question concerns ordinary package metadata or module management, then use goda when the relationship or impact analysis becomes more involved.

The repository also shows a build-time integration point. The README documents the following command for printing statistics while building a Go program:

go build -a --toolexec "goda exec" .

This changes the build tool execution path, so it should be introduced only when the project team understands how `goda exec` behaves in that environment. The README gives the command but does not document all output modes, failure behavior, or overhead implications. As a result, it is a documented integration point, not a complete production build policy.

License, releases, and upgrade boundaries

The repository identifies its license as MIT. That designation covers the project's licensing terms, but it does not answer questions about the licenses of dependencies pulled into a user's application. Users still need to review the licenses of modules in their own dependency graph, especially when a release process or distribution model has compliance requirements. No legal interpretation is provided here.

The repository is not archived, and the last push was on 2026-10-13. Recent releases include v0.10.2 on 2026-10-13, v0.10.1 on 2026-08-25, and v0.10.0 on 2026-08-25. The README's installation example uses `@latest`, so installing it follows the latest published module version rather than a version pinned by the repository's example.

The documented argument syntax warning creates an upgrade concern. Changes to command-line arguments or expression behavior may require updates to local scripts, Makefiles, CI jobs, and documentation. The repository includes a `Makefile` with `test`, `lint`, and `check` targets, but those targets document development checks for the project itself, not a migration procedure for downstream users. Before upgrading an installed goda binary, inspect any saved expressions and run the relevant `goda help expr` and `goda help format` output.

Editorial conclusion

Adopt goda when a Go project needs package-set queries, dependency graph inspection, or binary-size investigation beyond `go list` and `go mod`. Do not adopt it as a drop-in replacement for standard Go commands without first checking the Go version, Graphviz availability for graph rendering, and whether its expression syntax fits your workflow. The first checks are `go version`, the documented `go install` command, and a focused `goda list` or `goda graph` query in the target module.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. loov/goda on GitHub
4. README
5. Releases