go1.24 support

[ldez]

EDIT: since v1.64 golangci-lint supports go1.24 if compiled with go1.24 🎉

Additional Notes

Some package systems (like homebrew, nix, etc.) are "slow" in propagating the new Go version.
After a new release of Go and golangci-lint, those systems can use an old Go version to compile golangci-lint resulting in a non-working binary (high memory usage, missing symbol, etc.).

In this situation, you should use the official binaries, or compile golangci-lint manually with the right Go version, or help these package systems to support this new Go version.

We are not responsible for package systems that don't use official binaries.

To validate the Go version used to compile: golangci-lint version

$ golangci-lint version
golangci-lint has version 1.64.2 built with go1.24.0 from 1dae906b on 2025-02-11T21:44:55Z

---

Is golangci-lint support go1.24?

No, and yes.

Basically, golangci-lint supports Go versions that are lower or equal to the Go version used to build it.

In addition, of the Go version used to build it, some linters could need to be updated to support newer versions of Go, and internal pieces of golangci-lint could also need to be updated.

The current binaries from the releases page and the Docker images have been built with go1.23 and will be built with go1.23 as long as go1.24 is not GA.
So those binaries/images don't support go1.24 (new elements and internal Go changes).

https://golangci-lint.run/welcome/faq/#which-go-versions-are-supported

---
title: Is golangci-lint support go1.24?
---
flowchart
    A([compiled with go1.24?]) -- yes --> B([needs update of the internals of golangci-lint?])
    A -- no --> C((NO))
    B -- yes --> D([uses right internal pieces?])
    B -- no --> E((YES))
    D -- yes --> G((YES))
    D -- no --> F((NO))

Loading

You can follow the PR #5224 to see the progress on this topic.

https://go.dev/wiki/Go-Release-Cycle

Additional Notes

Some package systems (like homebrew, nix, etc.) are "slow" in propagating the new Go version.
After a new release of Go and golangci-lint, those systems can use an old Go version to compile golangci-lint resulting in a non-working binary (high memory usage, missing symbol, etc.).

In this situation, you should use the official binaries, or compile golangci-lint manually with the right Go version, or help these package systems to support this new Go version.

We are not responsible for package systems that don't use official binaries.

To validate the Go version used to compile: golangci-lint version

$ golangci-lint version
golangci-lint has version 1.64.2 built with go1.24.0 from 1dae906b on 2025-02-11T21:44:55Z

---

golangci-lint is a free and open-source project built by volunteers.

If you value it, please consider donating or asking your company to do so, we appreciate it! ❤️

---

• fix: type aliases Antonboom/nilnil#47

[pdarulewski]

Go 1.24 will introduce the tool directive: https://tip.golang.org/doc/modules/managing-dependencies#tools so it won't be needed to create tools.go with build tags.

Does it change anything in terms of recommendations for installing golangci-lint from sources here? I think it would be nice to have all tools (linters, formatters, code generations, etc.) in a single place, so everyone in a team could use the same toolset, regardless of the package manager and operating system.

[ldez]

Does it change anything in terms of recommendations for installing golangci-lint from sources here?

No, it doesn't change the core of the problem, it will just increase the problems.

The arguments inside the doc are even more than accurate with this new command because, for example, it will merge the dependencies of your projects with the dependencies of the tools.

If you install golang.org/x/tools/cmd/stringer you will have 3 indirect dependencies that golangci-lint uses.

module github.com/golangci/sandbox

go 1.22.0

toolchain go1.24rc1

tool golang.org/x/tools/cmd/stringer

require (
	golang.org/x/mod v0.22.0 // indirect
	golang.org/x/sync v0.10.0 // indirect
	golang.org/x/tools v0.28.0 // indirect
)

So it can influence golangci-lint.

And the opposite is also right, your project dependencies will be influenced by the dependencies of golangci-lint.

[ldez]

I have a problem with the release, I'm on the topic.

https://github.com/golangci/golangci-lint/actions/runs/13271625662/job/37052177243#logs

[ldez]

There is a change inside the GitHub Action: mono is missing.

So I disabled Chocolatey.

I will try to find the reason for the disappearance of mono later.

[ldez]

I was forced to create bugfix releases because of the problem related to Chocolatey, so v1.64.0 and v1.64.1 has been cancelled, v1.64.2 is the stable release.

[srenatus]

Bumping to the latest release, 1.64.2, for using golangci-lint with Go 1.24, I got a panic from revive: mgechev/revive#1228 -- Sharing this here because others might be running into the same thing.

[pfi79]

Go 1.24 adds new standard packages (e.g. crypto/sha3) that are not in the gci linter.

EDIT: daixiang0/gci#228

[ldez]

@pfi79 could open an issue on https://github.com/daixiang0/gci?

[ldez]

I opened a PR on gci daixiang0/gci#227

[srenatus]

Bumping to the latest release, 1.64.2, for using golangci-lint with Go 1.24, I got a panic from revive: mgechev/revive#1228 -- Sharing this here because others might be running into the same thing.

My problem was resolved by #5399. Thanks for publishing a new release so quickly. 👏

[ldez]

I hope you enjoyed my work, please consider donating or asking your company to do so.
My only source of revenue is donations.
This will be appreciated, thank you ❤️

https://donate.golangci.org/
https://donate.ldez.dev/