golangci-lint version resolution broken

[Beatheru]

What version of Go, VS Code & VS Code Go extension are you using?

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.

  • go version go1.25.5 linux/amd64

• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.

  • golang.org/x/tools/gopls v0.21.0

• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.

  • 1.107.0
    618725e67565b290ba4da6fe2d29f8fa1d4e3622
    x64

• Check your installed extensions to get the version of the VS Code Go extension

  • 0.52.1

• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.
  go: /home/beath/.gvm/gos/go1.25.5/bin/go: go version go1.25.5 linux/amd64

  gotests: not installed
  impl: not installed
  goplay: not installed
  dlv: /home/beath/.gvm/pkgsets/go1.25.5/global/bin/dlv (version: v1.26.0 built with go: go1.25.5)
  golangci-lint: /home/beath/.gvm/pkgsets/go1.25.5/global/bin/golangci-lint (version: v2.7.2 built with go: go1.25.4)
  gopls: /home/beath/.gvm/pkgsets/go1.25.5/global/bin/gopls (version: v0.21.0 built with go: go1.25.5)

Share the Go related settings you have added/edited

{
  "go.lintTool": "golangci-lint",
  "go.lintFlags": ["--path-mode=abs"],
  "go.formatTool": "custom",
  "go.alternateTools": {
    "customFormatter": "golangci-lint"
  },
  "go.formatFlags": ["fmt", "--stdin"]
}

Describe the bug

Commit bca1404 has broken the way this extension resolves the version of golangci-lint. Previously if "go.lintTool" was set to "golangci-lint" it would dynamically determine the version of the binary by running go version -m. Now it determines the version purely based on if "go.lintTool" is "golangci-lint" or "golangci-lint-v2".

This results in previous errors of calling the linter with wrong flags like unknown flag: --print-issued-lines if you have "go.lintTool" set to "golangci-lint" but have v2. Going forward, this would necessarily mean that if you want to use v2 of the linter you must have "go.lintTool" set to "golangci-lint-v2" and also have a "golangci-lint-v2" binary in your $GOPATH/bin. This is kind of annoying though if you still want to keep using "golangci-lint" in the CLI as you must have a "golangci-lint" binary and a "golangci-lint-v2" binary. If this is expected behavior then the golangci-lint integrations documentation must also be edited. If this is not expected I would be happy to make the change.

Steps to reproduce the behavior:

1. Install golangci-lint v2 manually via the binary installation method which produces a "golangci-lint" binary in your $GOPATH/bin
2. Update the extension to v0.52.0 or later
3. Trigger lint from vscode by saving a file
4. See error in the output

[Beatheru]

I am not sure if related but v0.52.0 caused me getting "can't find goimports" errors yesterday. Which wasn't and isn't the case with v0.50.0. Go version seems irrelevant, as I tried with both v1.25.1 and Go v1.25.5

This would not be related. The issue strictly concerns the golangci-lint version resolution, though it sounds like it could be related to some of the formatting changes made from v0.50.0 to v0.52.0.

[ufukty]

@Beatheru You are correct. Sorry for noise.

[thiagodeev]

The same issue is happening with me.
Previously, everything worked as normally (I have golangci-lint installed with asdf), but suddenly it stopped working. It seems it's related to this new update.

My custom config:

  "go.lintTool": "golangci-lint",
  "go.lintFlags": [
    "--path-mode=abs",
    "--allow-parallel-runners",
    "--fix"
  ],

  "go.formatTool": "custom",
  "go.alternateTools": {
    "customFormatter": "golangci-lint"
  },
  "go.formatFlags": [
    "fmt",
    "--stdin"
  ],

Output in the Output tab:

2025-12-30 12:42:15.619 [info] Starting linting the current package at /home/thiagodeev/development/nethermind/starknet.go/typeddata
2025-12-30 12:42:15.694 [error] Error while running tool: /home/thiagodeev/.gvm/pkgsets/go1.25/global/bin/golangci-lint run --path-mode=abs --allow-parallel-runners --fix --issues-exit-code=0 --print-issued-lines=false --out-format=line-number
2025-12-30 12:42:15.694 [error] Error: unknown flag: --path-mode
Failed executing command with error: unknown flag: --path-mode

It's ignoring my local version and using the golangci-lint inside .gvm/pkgsets/go1.25/global/bin/, which is v1. If it's not installed, it installs it.

It works if I use "go.lintTool": "golangci-lint-v2", because it installs it in .gvm/pkgsets/go1.25/global/bin/golangci-lint-v2, so it continues ignoring my local version.

I want to use my already installed local version instead of a new one provided by the extension

[h9jiang]

Hi @Beatheru,

I'm very sorry for causing this behavior. I merged that CL because the golang ci lint official doc recommend install golang ci lint using a script, and the binary downloaded was not built from a clean, officially tagged release version of the module.

So I prematurely thought most golangci-lint users are downloading golangci-lint using the recommended way. (and it is going to be a big problem for most of the user)

But based on number of affect developers, seems like more people are using go install. I'm happy to revert that CL to make it work.

Another reason for the suffix of the binary is because golangci-lint v1 and v2 share the same binary name, so we just use a version suffix to manage them by the extension.

I will revert the change and probably have a 0.52.1 sometime in Jan with a few other fixes.

[jakebailey]

Another datapoint is golangci-lint custom, which builds a binary with custom analyzers, which has another path altogether you have you have to override to work in the extension.

I would just assume anyone using it these days is using v2 and up anyway, if you need to make a choice as to what to offer for upgrades (though I personally avoid that entirely).

[Beatheru]

So I prematurely thought most golangci-lint users are downloading golangci-lint using the recommended way. (and it is going to be a big problem for most of the user)

I don't think the method of installation matters. Both the script and via go install (I installed using the script) will produce a golangci-lint binary. And you are correct that both v1 and v2 do share the same binary name, which is why I think the old way of determining the version using go version -m worked fine.

The problem is when you switch "go.lintTool" to "golangci-lint-v2" the extension is looking for a golangci-lint-v2 binary which most people will not have unless they install golangci-lint-v2 via the extension.

[gopherbot]

Change https://go.dev/cl/733940 mentions this issue: Revert "src: skip version check for golangci-lint"

[h9jiang]

Hi @Beatheru

For the context, when the last issue is raised, I left a comment there because I remember the golangci-lint installed by the script was not built from a clean, officially tagged release version of the module. So the extension can not figure out the version of the binary.

There must be some changes happened in between, I just tried the same script and this script is producing the clean build this time.

I can revert the change that previously made so the version determination will be done by the go version -m.

For now, you can switch the extension to v0.50.0 to keep the old behavior, and we can release v0.52.1 soon to make it work.

If you have any suggestions, feel free to post here. Thank you.

[Beatheru]

Oh I see, thanks for the context. I can see how that is tricky since that's reliant on the golangci-lint team. It would be a shame for you to revert this change and then have that previous issue happen again due to something you don't really have control over.

Unfortunately I don't really have any concrete suggestions. I initially thought the same as jakebailey, that it's pretty fair to assume that everyone nowadays is using v2, but given the relatively recent timestamp of that other issue it seems like that may not be the case.

The main pain point is that using "golangci-lint-v2" will try to search for a binary called golangci-lint-v2 when most people will probably have golangci-lint. It might be more ergonomic to just have one lintTool option "golangci-lint" and then create another option where the user can specify "v1" or "v2".

I feel that given the vast difference between v1 and v2 there needs to be a fool-proof way of determining the version (while preserving convenience) unless v1 support gets dropped.

[jakebailey]

go version -m seems like the right thing to do, or just golangci-lint version (which probably isn't that stable).

I'm somewhat surprised this versioning matters all that much; I had thought golangci-lint had stable JSON output.

[h9jiang]

I think go version -m is the right approach in general, I also find it surprising that they decide to use a custom build (at the time when the issue was filed).

let's revert the change. Seems like this issue have more participants than the old one, and my previous observation is no longer true.

I hope developers will use go install to install tools instead of the scripts to ensure it is built from clean, officially tagged release version. It is always the recommended way of installation, from the Go Team's perspective.