discussion: vendoring of golangci-lint deps for easier usage as tool dependency

[brandon1024]

Welcome

• Yes, I'm using a binary release within 2 latest releases. Only such installations are supported.
• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've read the typecheck section of the FAQ.
• Yes, I've tried with the standalone linter if available (e.g., gocritic, go vet, etc.).
• I agree to follow this project's Code of Conduct

How did you install golangci-lint?

go tool

Description of the problem

Hello 👋

First and foremost, thanks a bunch for your efforts in golanci-lint. I've integrated golangci-lint in a handful of projects I maintain at Siemens and it has been a huge help in maintaining consistent style and code quality.

One of the biggest pain points we've had with golangci-lint is the distribution and integration in our build systems. Installations are closely tied to the Go toolchain version used to build the project, so whenever we upgrade Go for a project, users will also need to upgrade golangci-lint as well. When you maintain a lot of projects using different versions of Go, this becomes a headache, and this headache is passed down to all project developers.

 ╰╼ ▶ golangci-lint run
Error: can't load config: the Go language version (go1.24) used to build golangci-lint is lower than the targeted Go version (1.26.0)

Despite being discouraged, we've completely switched to using golangci-lint as a tool dependency in dedicated go modules to make our life easier. This solution has its quirks, but we can live with this.

$ cat tools/golangci-lint.mod
module code.siemens.com/my/project.git/tools/golangci-lint

go 1.26.0

tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint

require (
	4d63.com/gocheckcompilerdirectives v1.3.0 // indirect
        ...
)

$ go tool -modfile=tools/golangci-lint.mod golangci-lint run

It's well known that golangci-lint has a pretty large dependency tree, and I understand that this is one of the main reasons that maintaining golangci-lint as a tool dependency is discouraged. I've been asking myself why golanci-lint hasn't explored vendoring of linter dependencies instead? Vendoring comes with it's own set of challenges, but it would make golangci-lint completely self sufficient, and this means that downstream users could easily pull in golangci-lint (go install, go run golangci-lint, go tool golangci-lint run, etc) without the difficulties that come from the large dependency graph.

I'm curious if golangci-lint maintainters have considered this approach, and if so why was it decided not to vendor dependencies?

Thanks again :-)

Version of golangci-lint

Details

N/A

Configuration

Details

N/A

Go environment

Details

N/A

Verbose output of running

Details

N/A

A minimal reproducible example or link to a public repository

Details

N/A

Validation

• Yes, I've included all information above (version, config, etc.).

Supporter

• I am a sponsor/backer of this project.

[brandon1024]

Apologies -- I accidentally opened this as a bug. A feature request might have been more suitable.

[ldez]

Hello,

The problems explained inside the documentation related to the installation from source are not fixed by vendoring dependencies.

The two main problems are:

• the Go dependency
• the dependencies

Previous versions of golangci-lint should not be built with never version of Go.
I explained that in all issues about the support of a newer Go version (ex: #6272)

The vendoring doesn't change anything about the modification of the dependencies, especially when using go tool.

And to be a bit more exhaustive, I have discussed directly with the Go team and they don't have solutions too.

[brandon1024]

Previous versions of golangci-lint should not be built with never version of Go.

Totally, I'm aware and understand why that's the case. From my point of view, that's not really a problem here. It's up to project maintainers to ensure the version of golangci-lint is suitable for their particular build setup.

The vendoring doesn't change anything about the modification of the dependencies, especially when using go tool.

You lost me here. Can you elaborate?