golangci-lint configuration file

[sam-github]

golangci-lint can run all the currently enabled linters, and as far as I
can tell, does it in under 5 seconds as opposed to over 180 seconds
(compare time make cilint and time make lint).

Some of the linters that are listed in the "enabled" section but
commented out looked like a good idea to me, and fairly low hanging
fruit to fix, but they are not passing at the moment.

All the linters covered in the current Makefile are run.

TODO:

• replace lint target in Makefile with golangci-lint
• remove .github/workflow/errcheck.yml

---

Just a suggestion. It might be much faster, and yet do the same thing, win-win. I did some fixing of things gocritic didn't like (its a big fan of switch statements over if/if else/if else/else series), but then stopped and disabled it. Some of the sec warnings seem not applicable to wtf given that it does shell out to user-defined commands at times, so enabling gosec would involve whitelisting some of the warnings. Etc.

On the down side, since this is passing, I won't see the line-annotation feature that is supposed to be enabled... maybe I should enable a couple of the failing linters temporarily in the PR, so that feature is visible?

[sam-github]

Its possible (see golangci/golangci-lint#825) that this is because go build (no args) tries to make a ./wtf executable, but there is already a ./wtf/ directory.

[sam-github]

The inline annotations are nice (the existing integration likely has them, too, that's not an advantage).

Turns out it was just a ./... arg that's needed in the CI action (though not locally).

[sam-github]

Times for runs can be seen below. golangci-lint was 1m, imports check 51 sec, the others are 2m+. A small win.

[senorprogrammer]

This will be great on the CI system. For local installs we'll need to ensure that the user has it installed. What do you think of changing make lint to check that golangci-lint is present. If it is, use that. If not, inform on where to get it (https://golangci-lint.run/usage/install/#local-installation) and fall back to the old method.

That way we don't need two lint commands.

[senorprogrammer]

And this change to the original lint command speeds it up quite a bit, making it only 7x slower than golangci-lint (the original version is 20x slower than this PR on my machine):

lint:
	@echo "\033[35mhttps://github.com/kisielk/errcheck\033[0m"
	errcheck ./app ./cfg ./flags ./help ./logger ./modules/... ./utils ./view ./wtf
	errcheck ./main.go

	@echo "\033[35mhttps://golang.org/cmd/vet/k\033[0m"
	go vet ./app ./cfg ./flags ./help ./logger ./modules/... ./utils ./view ./wtf
	go vet ./main.go

	@echo "\033[35m# https://staticcheck.io/docs/k\033[0m"
	staticcheck ./app ./cfg ./flags ./help ./logger ./modules/... ./utils ./view ./wtf 
	staticcheck ./main.go

	@echo "\033[35m# https://github.com/mdempsky/unconvert\033[0m"
	unconvert ./...

[sam-github]

Yes, running the tool against multiple inputs simultaneously helps the current stuff a lot, its basically the optimization that golangci-lint does.

The current lint target assumes errcheck and staticcheck were installed globally, the cilint target assumes golantlint-ci is installed globally, its the same situation, isn't it? I'm pretty sure when I first tried to run make lint, I just looked up the name of the tools from the comments in the Makefile, and did a manual got get ... on them, then re-ran.

The build tool situation with go modules seems a bit obscure ATM, from golang/go#25922 I've found and tried https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md, but I still needed a setup style target:

setup:
	GOBIN=$$PWD/bin go install github.com/golangci/golangci-lint

# Make the obvious lint target depend on setup, so it works "out of the box"
lint: setup just-lint

# If you have done setup already, don't repeat it, its slow
just-lint:
        ./bin/golangci-lint run 

Other than an explicit setup target, I don't see a way of ensuring dev-time tools are available. Adding a tools.go to the above seems to be a way to ensure exact versions of the tools are installed, which could be a big deal for a long-running large project that needs stable builds over years, but not so much here.

[sam-github]

I should have mentioned, I called this cilint just so I could leave the original lint target in. Its a poor name, given that ci doesn't use it, it just uses the action. Oops.

I think the cilint target should be renamed lint, and the (current) lint target deleted.

[senorprogrammer]

That’s an excellent point about the current one, I’d forgotten they’re not go standard. Let’s go straight with golintci.

[sam-github]

Btw, I don't use vscode, but it has golangci-lint integrations: https://golangci-lint.run/usage/integrations/, might be useful (I'm not sure if the standalone tools also do that).

[sam-github]

ok, give me a chance to tidy this up a bit, I'll add at least a couple comments so people know how to do the setup.

Actually, WDYT, setup target, or just a comment saying "go get it"? I suspect for vscode integration it might need to be global anyhow.

[senorprogrammer]

Go with the simplest to implement option at this stage. I suspect 99% of contributors don’t use the make tooling so having it on CI is really what matters

[jirfag]

JFYI we've launched v1 with support of caching and without slow docker image pulling, it works much faster