Pin viper module to v1.12.0 in go.mod

[busser]

I've been trying to get golangci-lint to work with go tool. The only
issue I've run into so far is related to dependency versions.

I know that golangci-lint's documentation warns against compiling
golangci-lint ourselves, since the resulting binary is untested.
However, in practice it's very close to working.

I'm importing the golangci-lint module into a module that also imports
viper. However, while golangci-lint imports v1.12.0, my module
imports v1.19.0 (the latest version). When I run go tool golangci-lint
the Go compiler compiles golangci-lint with [email protected], which
breaks part of the revive linter (see issue #3280). It possibly breaks
parts of other linters, but my specific configuration did not reveal it.

I'm currently working around this by removing the configuration that
golangci-lint can't handle when using [email protected]. However I
believe we can get the Go compiler to use [email protected] for
golangci-lint and whatever other version for any module that would
import golangci-lint. The trick is to add a replacement to
golangci-lint's go.mod:

replace github.com/spf13/viper => github.com/spf13/viper v1.12.0

I've experimented with this fix by using Go workspaces and it seems to
work as desired. The parent module can still use [email protected] and
the issue in the revive linter does not occur.

This change requires disabling the gomoddirectives linter in a couple
of golangci-lint's tests. Those tests are completely unrelated to that
specific linter or to go.mod, so I figure it's fine.

[CLAassistant]

All committers have signed the CLA.

[ldez]

sorry I made a mistake, I wanted to clean your previous PR.

FYI, the base branch can be changed inside the GitHub UI, you don't need to recreate a PR just to change the base branch.

But replace directives are not transitive, so it doesn't "pin" a dependency.

Also, golangci-lint should not be used as a library, we don't support that.

[ldez]

We strongly discourage using go tools or the tools pattern.

But if I'm forced to provide recommendations:

Method 1 (dedicated module file)

# Create a dedicated module file
go mod init -modfile=golangci-lint.mod <your_module_path>/golangci-lint
# Example: go mod init -modfile=golangci-lint.mod github.com/org/repo/golangci-lint

# Add golangci-lint as a tool
go get -tool -modfile=golangci-lint.mod github.com/golangci/golangci-lint/cmd/[email protected]

# Run golangci-lint as a tool
go tool -modfile=golangci-lint.mod golangci-lint run

Method 2 (dedicated module)

# Create a dedicated directory
mkdir golangci-lint

# Create a dedicated module file
go mod init -modfile=golangci-lint/go.mod <your_module_path>/golangci-lint
# Example: go mod init -modfile=golangci-lint/go.mod github.com/org/repo/golangci-lint

# Setup a Go workspace
go work init . golangci-lint

# Add golangci-lint as a tool
go get -tool -modfile=golangci-lint/go.mod github.com/golangci/golangci-lint/cmd/[email protected]

# Run golangci-lint as a tool
go tool golangci-lint run

[ccoVeille]

Thanks for sharing this @ldez

Could you consider to document it in the README and website?

I know you keep warning people about the risks. I saw you posting warnings again and again over the past months.
But now, go tool is here, more and more people will try using it anyway.

What you documented is very interesting, I think it's a valuable solution

[ldez]

#5549

[ldez]

But now, go tool is here, more and more people will try using it anyway.

I want to be clear: I will continue to strongly discourage this usage, this will not become a supported or recommended method.

This is just a way to limit problems.

Users can do what they want, but they cannot complain or ask for changes related to that.