go-recipes: A Command Cookbook for Go Tooling

The Gap Between Knowing a Tool Exists and Knowing the Command

The README opens with a plain description: "Handy well-known and lesser-known tools for Go projects." That sentence is the whole product. The repository does not implement coverage collection, dependency graphing or mutation testing. It tells you which existing binary to install and what to type. The problem it addresses is discovery friction. A Go engineer who wants a treemap of test coverage has to find go-cover-treemap, read its flags, and work out how to pipe a coverage profile into it. go-recipes collapses that into one heading and one command block. The audience is narrow and specific: developers and CI maintainers working on Go modules who are comfortable installing command line tools from source and who want a starting command rather than a conceptual explanation. It is less useful for someone learning Go, because nothing here explains why a coverage profile is shaped the way it is, and less useful for polyglot teams, because every entry assumes a Go toolchain and a module layout.

A Table of Contents That Doubles as the Architecture

There is no architecture to describe, and that is worth stating plainly. The repository's structure is its contents list. The README groups recipes under headings, and the visible ones are Test, Dependencies and Code Visualization. The Test group covers coverage browsing, coverage diffing, test shuffling, fuzzing, goroutine leak detection, mutation testing and test output formatting. The Dependencies group covers upgrading modules, reading Go versions of upstream modules, graphing module and package imports, scraping dependency licences with go-licenses, and interactive explorers such as goda and modview. Code Visualization covers C4 diagrams with go-structurizr, call graphs with callgraph and go-callvis, PlantUML output with goplantuml and go-plantuml, and 3D representations with dep-tree and gocity. The data flow is therefore human, not programmatic: you read a heading, copy a shell command, and run it in your own repository. The repository ships a badge file referenced from the README, but the material does not indicate that it builds or executes anything. Treat it as documentation with a curated index, not as a library you import.

From Readme to Terminal: What Actually Gets Typed

The recipes are shell invocations against the standard Go toolchain plus third-party binaries. Coverage work starts from a profile produced by go test with the coverprofile flag, which is the conventional entry point for the coverage recipes listed under Test. Dependency inspection leans on the go mod family of commands: the README lists recipes for upgrading dependencies, for reading the Go version of the current module, for listing upstream modules that lack a Go version, and for listing available module versions. Several entries depend on external installs rather than the toolchain, so a recipe such as the go-licenses scrape or the modgraphviz graph requires you to fetch that binary first. Two entries are worth calling out because they describe workflow rather than a single command: the replace directive recipe and the go.work recipe both cover patching a dependency locally, which is the situation where you need to change upstream code without forking it. The README gives these as recipes, not as a recommended practice, and the difference between replace and go.work matters for whether the patch is visible to other modules in your workspace.

Where the Cookbook Format Breaks Down

The main limitation is version drift. The README lists commands without pinning the versions of the tools they invoke, and Go tooling changes quickly. A recipe that worked when written may reference a flag that has since been renamed or a binary that no longer builds against a current toolchain. The repository has no test suite that would catch this, because there is nothing to test: the commands are text. The maintenance signal is the release cadence, which the release list shows as annual, with entries labelled as Christmas updates in 2023, 2024 and a 2025 update dated 2025-12-21. That cadence tells you the index is refreshed roughly once a year, so a tool that changed in March may not be reflected until December. A second limitation is scope: the recipes assume a Unix-like shell and a conventional module layout, and the material gives no indication of Windows-specific variants. Third, and most important for evaluation, the repository provides no evidence about the quality of the tools it lists. Inclusion is a curation decision, not a review, and the README does not rank entries or mark any as deprecated.

What to Compare It Against

The obvious alternative is the Go wiki and the golang.org documentation, which cover the toolchain itself but do not collect third-party coverage, visualisation and mutation testing tools in one place. A closer comparison is a general awesome list for Go, which also indexes tools but typically organises by project category rather than by the task you are trying to perform. That is the real difference in approach: go-recipes is task-first. The heading is not "go-cover-treemap" but "Make treemap of coverage with go-cover-treemap", which means you find the entry by knowing what you want to see, not by knowing the tool's name. The cost of that framing is that entries are single-purpose and shallow. An awesome list entry might point you at a project's documentation, roadmap and issue tracker; a go-recipes entry gives you a command and moves on. If you need to understand a tool's design or judge its reliability, go-recipes is the wrong starting point and you should go to the tool's own repository instead. If you need the command right now, it is faster.

Licence, Maintenance and the Cost of Depending on an Index

The repository is MIT licensed, which permits reuse and modification with attribution and without warranty, but that licence covers the text of the index and not the tools it points to. Each listed binary carries its own licence, and the README itself includes a recipe for scraping upstream dependency licences with go-licenses, which is a reasonable reminder that the index is not a licence inventory. If you vendor go-recipes content into internal documentation, you are copying MIT-licensed text and should keep the attribution. Upgrade cost is low in the sense that there is no dependency to bump, and high in the sense that the recipes themselves rot. The annual release cadence means a command copied today may be stale within a year. The practical mitigation is to treat each recipe as a hypothesis and confirm it against the tool's current documentation before adding it to a CI pipeline, where a broken command fails the build rather than annoying a developer.

Who Should Keep This Bookmarked

Keep go-recipes open if you maintain a Go module and periodically need to answer questions like which upstream modules can be upgraded, what the import graph looks like, or where test coverage is thin. The recipes for go test shuffling, sequential and parallel test runs, and fuzz test execution are the kind of thing you look up once and then keep in a Makefile. Skip it if you need a supported library, a stable API, or anything that runs without you installing the underlying binaries yourself. The repository is a map, and maps do not walk the route. What to verify before relying on any single entry: run the command against your own module on your current Go version, confirm the third-party binary still installs, and check the tool's own repository for the flag semantics, since go-recipes does not document them.

Editorial conclusion

Adopt go-recipes if you already know which Go question you need answered and want the exact command rather than a tutorial. Do not adopt it if you expect a maintained dependency, a wrapper, or a tool that runs anything on your behalf: it is a Markdown index with an MIT licence and no runtime. Before trusting a recipe, run the underlying tool against your own module on your own Go version, because the README lists commands without pinning versions and several entries wrap third-party binaries that may not build against current toolchains.

Official sources

1. Issues
2. License: MIT
3. nikolaydubina/go-recipes on GitHub
4. README
5. Releases