golangci-lint-action VS golangci-lint

# source: https://github.com/golangci/golangci-lint-action?tab=readme-ov-file#how-to-use name: golangci-lint on: push: branches: - master - main pull_request: permissions: contents: read # Optional: allow read access to pull request. Use with `only-new-issues` option. # pull-requests: read jobs: golangci: name: lint runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-go@v4 with: go-version: '1.21' cache: false - name: golangci-lint uses: golangci/golangci-lint-action@v3 with: # Require: The version of golangci-lint to use. # When `install-mode` is `binary` (default) the value can be v1.2 or v1.2.3 or `latest` to use the latest version. # When `install-mode` is `goinstall` the value can be v1.2.3, `latest`, or the hash of a commit. version: v1.54 # Optional: working directory, useful for monorepos # working-directory: somedir # Optional: golangci-lint command line arguments. # # Note: By default, the `.golangci.yml` file should be at the root of the repository. # The location of the configuration file can be changed by using `--config=` # args: --timeout=30m --config=/my/path/.golangci.yml --issues-exit-code=0 # Optional: show only new issues if it's a pull request. The default value is `false`. # only-new-issues: true # Optional: if set to true, then all caching functionality will be completely disabled, # takes precedence over all other caching options. # skip-cache: true # Optional: if set to true, then the action won't cache or restore ~/go/pkg. # skip-pkg-cache: true # Optional: if set to true, then the action won't cache or restore ~/.cache/go-build. # skip-build-cache: true # Optional: The mode to install golangci-lint. It can be 'binary' or 'goinstall'. # install-mode: "goinstall"

Finally, we can use golangci-lint's provided GitHub Action for linting - it runs golangci-lint on the workflow runner's clone of the repo and outputs an error code if any Go file in the repo fails rules of any linters in golangci-lint. Note that golangci-lint fails if the AST cannot be parsed (i.e. if there are any syntax errors), so it can also be used for checking syntax correctness, which itself is a good proxy for checking for merge conflict strings. We can fail-fast with any checks this way - there's no need to spin up a compilation and a go test invocation if there are syntax errors.

If you want to run golangci-lint in CI, you can use golangci-lint-action same as other actions.

One of the checkers in golangci-lint does this. I forget which one.

golangci-lint rolls up lot of linters and checkers into a single binary.

There is a config file too.

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

golangci-lint is an amazing open-source tool for CI in Go projects. Basically, it's an aggregator and a Go linters runner that makes life easier for developers. It includes all the well-known liners by default but also provides an easy way to integrate new ones.

Fun fact: We actually use a code linter via golangci-linter to catch misspellings in code/comments using client9/misspell.

The "standard linter" in Go is https://golangci-lint.run/ , which includes [1] the absolutely-vital errcheck which will do that for you.

For an Advent of Code challenge you may want to turn off a lot of other things, since the linter is broadly tuned for production, public code by default and you're creating burner code and don't care whether or not you have godoc comments for your functions, for instance. But I suggest using golangci-lint rather than errcheck directly because there's some other things you may find useful, like ineffassign, exportloopref, etc.

[1]: https://golangci-lint.run/usage/linters/

golangci-lint recently integrated go-check-sumtype. I recommend using golangci-lint as a pre-commit hook, but if you're in a real hurry you can replace "go build" with a shell script that runs go-check-sumtype instead. This is probably better than a weird hack, not that you're saying that the weird hack is a good idea anyhow.

Golangci-lint is a tool for checking Go code quality, finding issues, bugs, and style problems. It helps keep the code clean and maintainable.

This is such an infuriating problem. I'm convinced I'm using Go wrong, because I simply can't understand how this doesn't make it a toy language. Why the $expletive am I wasting 20-30 and more minutes per week of my life looking for the source of an error!?

Have you seen https://github.com/tomarrell/wrapcheck? It's a linter than does a fairly good job of warning when an error originates from an external package but hasn't been wrapped in your codebase to make it unique or stacktraced. It comes with https://github.com/golangci/golangci-lint and can even be made part of your in-editor LSP diagnostics.

But still, it's not perfect. And so I remain convinced that I'm misunderstanding something fundamental about the language because not being able to consistently find the source of an error is such an egregious failing for a programming language.