One command runs more than a hundred Go linters
golangci-lint collects Go analyzers behind golangci-lint run. It loads packages once, runs compatible checks in parallel, caches work, and normalizes findings for terminals, editors, and CI systems. The catalog includes more than 100 linters, but the default configuration uses a smaller standard set. Teams can start with that set, disable a noisy check, or set the default to none and enable only named rules.
This shared runner solves a real maintenance problem. Installing govet, Staticcheck, gosec, revive, spelling checks, and formatters independently means separate versions, flags, exclusions, and output parsers. golangci-lint centralizes those choices in .golangci.yml, YAML, TOML, or JSON. The same convenience also couples upgrades: one runner release can update several analyzers at once, so a version bump deserves the same review as a compiler or build-tool change.
Released binaries avoid a 400-package source install
Our sandbox downloaded 400 Go packages in 79 seconds and built the project in 67 seconds. The checkout at commit 6fb5dee contained 1,839 files, about 75,251 source lines, and occupied 14 MB. That source path worked, but most users should skip it. The installation guide recommends released binaries and supplies commands for Linux, macOS, Windows, Docker, and several package managers.
The warning against go install is unusually direct. A local compilation inherits the user's Go version, dependency changes can produce an untested binary, module replacement directives do not apply transitively, and tool dependencies can affect one another. Homebrew can also build with an unexpected Go version, so the project prefers its binary assets. Pin the exact release in CI rather than asking each machine for whatever latest means that day.
What happened when we ran it
Our run completed the 79-second install and 67-second build without an error. The full Go test step then took 328 seconds and reported 142 passed, 0 failed out of 142. The repository had 9 GitHub CI workflow files, no Dockerfile in the measured signal, and a tests directory. These results came from an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Go 1.24, and no secrets.
Five and a half minutes for 142 tests is a noticeable contributor cost, even though every test passed. It says nothing about how long the runner will take on your repository because analyzer choice, package count, cache warmth, generated code, and type information all change the work. The defensible conclusion is that commit 6fb5dee had a clean build and test baseline in our stated environment.
Go version support follows the binary's compiler
The FAQ says golangci-lint supports the same two latest minor versions as the Go team. More importantly, it can generally analyze Go versions less than or equal to the version used to compile the binary. A new Go release may also require changes in bundled linters. When a project upgrades Go, verify the runner's build information and release support before making lint a required merge check.
Typecheck findings cannot simply be disabled like a style rule. The documentation explains that they represent package-loading or compilation problems that block later analysis. If the runner reports them, first make sure the complete package builds and that build tags, generated files, Go versions, and module state match CI. Suppressing a named linter will not repair a package the analyzer cannot load.
Version 2 migration saves a backup but drops comments
The v2 configuration has a schema and a migrate command. Migration saves the previous file with a backup suffix and converts many v1 settings. Defaults changed: v2 has no run timeout by default, generated-file exclusions became stricter, formatters moved into their own section, and old preset names were removed. The command does not carry over comments, deprecated options, or unknown fields.
Run migration on a branch, compare the files, restore policy comments by hand, and execute the old and new versions against the same commit. The reference configuration lists every option but explicitly says it is not a recommended working example. A short policy that names the checks the team understands is easier to maintain than enabling everything and accumulating exclusions until CI turns green.
Bundled analyzers can still panic or damage fixes
Version v2.13.1 was published on August 20, 2026. Two current reports describe nil-pointer panics in bundled analyzers: issue 6746 involves Staticcheck rule SA4023, while issue 6753 involves canonicalheader. The latter report used v2.13.1 built with Go 1.27 and enabled all linters. These reports do not invalidate our 142 passing project tests, but they show why a runner test suite cannot cover every target program.
Automatic fixes need an even stricter boundary. Issue 6671 shows modernize suggesting a change across two files, after which the runner placed part of one fix into the wrong file and produced invalid source. Keep fixes off protected branches, start from a clean worktree, inspect the diff, and run normal tests afterward. A linter is allowed to reject code; it should not receive permission to rewrite unreviewed work casually.
v2.13.1 is active enough to recommend
GitHub recorded 19,318 stars, a push on August 25, 2026, and 122 combined issues and pull requests. The August 20 release updated several bundled analyzers and dependencies. That activity is healthy for a tool tied closely to Go releases, although the combined open count is not a bug count. GPL-3.0 covers the runner, while bundled analyzers retain their own licenses.
Adopt golangci-lint when three or more Go checks need one stable CI contract. Pin v2.13.1 or a later tested release, validate the configuration, cache between runs, and upgrade on a branch. For a project that only wants go vet plus Staticcheck, the standalone commands remain easier to understand and troubleshoot.