golangci-lint VS errors

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

Hey, I try to figure out an elegant way to integrate golangci into a Go project.

All of this is nitpicking really, but I would suggest using linters, e.g. https://github.com/golangci/golangci-lint - sometimes annoying, but mostly just helps to avoid discussions like this (and plethora of bugs).

You should always use golangci-lint, which includes errcheck.

golangci lint - https://golangci-lint.run/

Code inspection golangci-lint

I disagree with at least half of your post, tooling in Go is amazing overall and there is one linter that pretty much every one is using: https://github.com/golangci/golangci-lint

https://github.com/cockroachdb/errors is the most featureful in this space, but is heavy if you don't need network portability, redaction, and all the other bells and whistles.

The cockroachdb/errors is too big

Golang is great. I mostly love it. However, collecting an error with relevant context and a nicely formatted stacktrace is kind of a mess of competing approaches. This this feature comparison is a good overview of the landscape.