Open mmorel-35 opened 2 days ago
This I'm not so sure about. I actually consider golangci-lint to be pretty bad software. I intentionally just use staticcheck because it gives me warnings that I care about. golangci-lint contains all kinds of unnecessary and questionable linters that I don't really care about. Did you find any lint failures we should fix?
What do you mean by bad software ? IMHO it a tool that provides the capabily to each go project to apply the linters they deseires with the possibility to configure them. It avoids having to install all those tools individually.
My intention is to provide a way to check that the generated code is valid according to basic validators like the one quoted here. By the way I even saw the use of io/util which is now deprecated and must be replaced by io or os. I do this in order to help avoiding technica debt and make things accessible to the users
I mean that it is hard to use well. The default linters are too broad. It doesn't run well with all linters (including staticcheck). I value having a low number of false positives, something that is true of all staticcheck lint checks but obviously not of all linters in golangci-lint. I have applied all the linters I desire, and it is the staticcheck linter. I do not think golangci-lint adds value.
Generated code is often exempt from lint checks because it's not written by humans. You can manually check the lint code if you want locally, and fix any issues that arises, but I don't think it's important for us to lint it generally.
Description
This uses golangci/golangci-lint-action instead of dominikh/staticcheck-action and define golangci-lint configuration.
golangci-lint is here configured to apply staticcheck rules and also gofmt.
gosec and govet are disabled to make the linting pass but deserve a closer look