golangci-lint compatibility mode configuration?

[sir-farfan]

Hello guys

Is there a way to specify in the .golangci.yml configuration file a version compatibility mode for golangci-lint?

For each repository I want to stick with a particular golangci-lint version in order to allow teammates to update their linter without worrying about bringing along unexpected or incompatible linter changes across projects.

[ldez]

Hello,

currently no, but I think we already have an issue on this topic.

We will not add compatibility support to allow running a very old configuration file with a newer golangci-lint, because it's almost impossible to manage.

The only thing we can maybe think about it's to allow checking a version defined in the config file to notify the user if the golangci-lint doesn't have the same version.

[sir-farfan]

At some point I had multiple binaries adding the version
go/bin/golangci-lint-v1.42.1
go/bin/golangci-lint-v1.40.0
and so on, it's not like we worry too much about free space in developer machines anymore.

How about automatically pulling the correct linter version and executing it instead for us?

[ldez]

golangci-lint is not Go, I'm not sure to understand the need to play with multiple versions.

I think that the root cause of your problem is your base configuration strategy, we can see 2 major strategies:

• CI oriented: use a fixed version (not latest) and use enable-all/disable for the linters. In this case, the dev must have the same version of the CI and/or when a dev uses a newer version he updates the CI and the golangci-lint configuration.
• local dev oriented: use a kind of latest version and use disable-all/enable for the linters. In this case, the dev can use any version (but there is a minimal version).

[bombsimon]

I think it would be weird to have the binary pull a binary of itself but a different version and then spawn a process with that binary if it's not the version in your .golangci.yml.

However you could pretty easily write something wrapping around golangci-lint to do this for you. I've not really had this use case personally but I figured it would be an alternative way to ensure CI would have a fixed version so I actually wrote a tiny version manager for golangci-lint; gclv. Maybe you could use something similar for your needs?

I agree with @ldez that a (min) version check is reasonable but not an actual manager that will download and link the binary.

[sir-farfan]

I'll try to force everyone to fix random issues caused by a surprise upgrade of the tool within the CI pipeline while checking the latest stable every time.

Hopefully it won't be as bad as a few month ago when I opened a project that is still using 1.21.0, or something old like that and decided to ignore all the issues found by the IDE.