Install gopls with Homebrew, apk, apt, dnf, MacPorts, Nix, pacman, zypper

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• gopls

Project history

gopls lives in the Go project's x/tools repository, the long-running home for Go analysis and developer tooling outside the main Go distribution. The gopls module appears as `golang.org/x/tools/gopls` and is documented on go.dev as the official language server for Go.

The project emerged during the Go modules era, when editor tooling needed to understand module-aware package loading, workspaces, diagnostics, code actions, and analysis across a changing build environment. Early tagged gopls releases in the tools repository begin with the `gopls/v0.2.x` series.

Over time, gopls moved from editor helper to a central Go development service. Its documentation covers editor-specific setup, LSP features, workspace behavior, analyzers, design notes, troubleshooting, and release notes.

Adoption history

The Go FAQ describes gopls as the Go team's supported language server for LSP-capable tools. That endorsement turned gopls into the default backend for many editors rather than a niche optional package.

Package-manager adoption is broad for a Go developer tool: the input facts list packages across Homebrew, Debian, Ubuntu, Fedora, Arch, Alpine, MacPorts, Nix, and openSUSE. That spread reflects its role as infrastructure for editors and CI-style tooling rather than a command users run manually every day.

Go telemetry planning has treated LSP-capable editors using gopls as a major part of the Go tool ecosystem, which is another sign that gopls became part of ordinary Go development workflows.

How it is used

Most users do not invoke gopls directly. Editors start it automatically to provide completion, hover, go-to-definition, diagnostics, formatting support, semantic tokens, code actions, references, and workspace operations.

Power users and editor maintainers use the documented settings, feature index, workspace documentation, and design notes to tune behavior or integrate gopls with less common LSP clients.

The gopls release documentation also shows it absorbing newer workflow surfaces, including an experimental MCP server mode in the v0.20.0 release line.

Why package nerds care

gopls is one of the clearest examples of a package-manager formula that is not an end-user app in the traditional sense but a local editor daemon. Installing it makes other tools work better.

It also matters because it centralizes Go-specific analysis in a versioned Go module. Package maintainers have to care about Go toolchain compatibility, editor compatibility, and x/tools release cadence, not just a single executable.

For Go ecosystem nerds, gopls marks the shift from editor-specific Go integrations such as gocode-era completion toward a shared language-server backend maintained by the Go project.

Timeline

• 2014: golang/tools repository created as the Go tools mirror.
• 2019: Early gopls tags appear in the x/tools repository.
• 2019: Go 1.13 makes module-aware workflows the default context for many Go developers.
• 2020s: go.dev publishes dedicated gopls documentation, editor guides, feature docs, and design notes.
• 2024: Go telemetry planning explicitly discusses LSP-capable editors that use gopls.
• 2025: gopls v0.20.0 release notes document experimental MCP server support.

Related projects

• golang.org/x/tools contains gopls and related Go developer tools such as goimports and stringer.
• The Language Server Protocol defines the editor-server boundary that gopls implements.
• The Go module system and proxy infrastructure shape how gopls loads and analyzes workspaces.

Sources

• https://github.com/golang/tools/tree/master/gopls
• https://go.dev/blog/gotelemetry
• https://go.dev/doc/faq
• https://go.dev/gopls/
• https://go.dev/gopls/release/v0.20.0
• https://go.dev/ref/mod
• https://pkg.go.dev/golang.org/x/tools/gopls