go-recipes: A Curated Reference of Tools and Techniques for Go Projects

What go-recipes Is: A Curated Catalog, Not a Library

go-recipes is a reference collection of tools for Go projects, described as "handy well-known and lesser-known tools for Go projects." The repository consists primarily of a README that links to external tools organized by workflow category. Engineers use it by reading the README on GitHub or cloning the repository and browsing locally.

The project follows the format of an awesome-list: a long, structured document that maps a task ("make a treemap of coverage") to a specific tool (go-cover-treemap) with a short explanation. The difference from a typical awesome-list is that go-recipes focuses on tooling rather than libraries or frameworks, and it provides command examples alongside the tool references.

The module in the repository is not what users import. The go.mod file shows the module is used to build the README page itself:

module github.com/nikolaydubina/go-recpies

go 1.23

require (
	github.com/nikolaydubina/mdpage v1.8.0 // indirect
	gopkg.in/yaml.v3 v3.0.1 // indirect
)

The module name in go.mod contains a typo: "go-recpies" instead of "go-recipes." This does not affect users of the reference, but it is worth noting that the module identifier does not match the repository name. The Go code in main.go and the template in page.yaml generate the README from structured data rather than serving as a tool for end users to run.

How the Repository Is Organized

The repository organizes its catalog into sections, each covering a distinct phase of Go development. The sections visible from the README table of contents include:

Test: coverage tools, test runners, test decorators, mutation testing, goroutine leak detection, fuzz testing, and test visualization. This section covers tools like go-cover-treemap for visual coverage analysis, gocovsh for terminal-based coverage browsing, goleak and leaktest for goroutine leak detection, gotestsum for JUnit reports and automatic test re-runs, and richgo and gotest for formatted test output.

Dependencies: upgrading modules, inspecting module graphs, checking license compliance (go-licenses), enforcing architecture rules (go-arch-lint, go-cleanarch), and using go mod directives like replace and go.work for local patching.

Code Visualization: generating C4 architecture diagrams (go-structurizr), call graphs (callgraph, go-callvis), PlantUML class diagrams (goplantuml, go-plantuml), 3D codebase charts (gocity), and entropy visualization (dep-tree).

The README is long enough that the table of contents alone spans several screens. Each entry links to an anchor in the document where the specific tool is described with a command example and sometimes a screenshot.

Coverage Tooling: What the Test Section Covers in Practice

The test section is one of the most detailed in the repository. It distinguishes between several distinct needs that the standard go test -cover command does not address:

Coverage visualization: go-cover-treemap generates a visual treemap from the standard coverage profile. gocovsh and nikandfor/cover provide terminal-based browsing. goc runs a coverage collector server that feeds a live view in VSCode.

Test organization: gotestsum handles JUnit report generation, automatic re-runs of failed tests, and identification of the slowest tests. tparse and richgo add color and structure to go test output without changing how tests run.

Advanced testing: goleak and leaktest both detect goroutine leaks, which are invisible to standard test runs. ooze, avito-tech/go-mutesting, and go-mutesting all perform mutation testing, which modifies your code and checks whether the test suite catches the changes. go-test-trace generates distributed traces from test runs.

The variety within just the testing category illustrates why the repository exists: standard Go tooling covers only a subset of what teams need for production-quality test infrastructure, and finding the right specialized tool for a specific need requires knowing it exists.

Dependency Recipes: Beyond go mod tidy

The dependencies section covers tooling that complements go mod tidy with analysis and visualization capabilities.

go-libyear measures the "libyear" of a module's dependencies: the combined age of all dependencies relative to their latest versions. This gives a single metric for how outdated a module's dependency tree is, expressed as a number of releases and a version delta.

modgraphviz generates a Graphviz-compatible graph of the upstream module dependency tree. import-graph does the same for package-level imports and can also scrape details about each upstream module.

go-licenses lists the licenses of all upstream dependencies, which is useful for license compliance audits before shipping a product.

go-arch-lint and go-cleanarch enforce architectural constraints by analyzing import paths and rejecting code that violates declared layering rules.

The replace and go.work directives are documented as native go mod techniques for locally patching a dependency without publishing a fork, which is a common need when debugging a third-party module.

How to Browse and Use go-recipes

Using go-recipes requires no installation. Engineers navigate to the README on GitHub or clone the repository:

git clone https://github.com/nikolaydubina/go-recipes

The README is a single Markdown file long enough that the table of contents is the primary navigation tool. Each section anchor links directly to the relevant recipe. The recipes themselves are short: a tool name, a brief description of what it does, and one or more command examples showing how to invoke it.

The tools referenced in go-recipes are all external projects. Each one must be installed separately with go install or the appropriate package manager for that tool. go-recipes provides the discovery layer; installation and configuration of each tool are out of scope for this repository.

The repository has annual release tags (Christmas updates: 2023-12-11, 2024-12-19 as v5, 2025-12-21). These indicate when the maintainer did a major curation pass, but the repository accepts contributions between releases. The last push was on 2026-09-09.

Limitations of a Curated Reference

A curated list ages differently from a library. The tools it references have their own maintenance trajectories, and go-recipes does not actively monitor whether a listed tool is still maintained or compatible with recent Go versions. An entry that was accurate when added may become stale if the referenced project is archived or abandoned.

The repository is also intentionally opinionated by omission. It does not attempt to be exhaustive; it covers tools the maintainer considers useful. Teams with specific needs (for example, a particular test harness or a specific static analysis tool) may find that the relevant tool is absent.

The comparable alternative for discovering Go tooling is the official Effective Go documentation and the Go blog, both maintained by the Go team. Those sources focus on language idioms and standard library usage rather than third-party tooling, which is why go-recipes occupies a different space.

The MIT license applies to the repository content itself (the README and the page-generation code), not to the tools it references. Each referenced tool carries its own license.

Editorial conclusion

go-recipes is useful for any Go team that wants a structured starting point for evaluating tooling outside the standard library. It is a reference, not a library: nothing is imported or installed from go-recipes itself. The tools it points to are maintained by their own authors and require separate installation and evaluation. The repository was last pushed on 2026-09-09 and has annual release tags. Check whether a listed tool is still maintained before adopting it, since some entries in large curated lists accumulate stale references over time.

Frequently asked questions

Official sources

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