With the new .golangci.yml in place, running the linter against our codebase surfaces existing violations. These need to be addressed before we can enable strict CI enforcement (fail on any violation) without relying on nolint directives or a baseline file as permanent workarounds.
Approach
- Run golangci-lint run ./... per component and capture the full list of violations
- Categorize findings by linter and severity to prioritize the work
- Fix violations per component, grouped into reviewable chunks:
- Auto-fixable issues (e.g., formatting, import ordering) — apply via golangci-lint run --fix where safe
- Manual fixes (e.g., error handling, unchecked returns, complexity)
- Cases where nolint is genuinely justified — must include a comment explaining why
- Validate each component passes cleanly before moving on
Guidelines
- Prefer real fixes over suppression — nolint directives should be the exception, not the norm
- Keep changes mechanical and scoped — do not refactor, improve, or restructure code beyond what is needed to resolve the violation
- Split PRs by component to keep reviews manageable and reduce merge conflict risk
- Ensure tests pass after each set of changes — lint fixes should not alter behavior
With the new
.golangci.ymlin place, running the linter against our codebase surfaces existing violations. These need to be addressed before we can enable strict CI enforcement (fail on any violation) without relying on nolint directives or a baseline file as permanent workarounds.Approach
Guidelines