Glonce

Buf ships production-grade LSP server for Protobuf

toolsThe Glonce editorsHacker News🔥66Glonce rating66Impact65Novelty70Relevance70Surprise35Players55Credibility85
Buf ships production-grade LSP server for Protobuf

Buf announced a fully-featured, production-grade Language Server Protocol (LSP) server for Protobuf, bundled directly into the Buf CLI. The Language Server Protocol is the standard API editors use to add language intelligence: go to definition, code completion, finding references, and semantics-aware syntax highlighting. Buf says Protobuf previously lacked the level of LSP support that other major programming languages already have, and it is positioning this release as the first modern IDE support Protobuf has had.

Setup differs by editor. In VSCode, installing the Buf extension is enough; it automatically detects or installs the Buf CLI, which bundles the LSP server. In Neovim, Buf engineers' own preferred editor, the setup requires installing the Buf CLI, adding the nvim-lspconfig plugin, calling lspconfig.buf_ls.setup{} in the Neovim config, and enabling it with vim.lsp.enable('buf-lsp'). For any other editor with LSP support, Buf says the only requirement is running the buf lsp serve command to start the server.

Under the hood, the LSP is built on protocompile, Buf's own Protobuf compiler frontend, which the company describes as fully compliant with the Protobuf spec and faster and more flexible than Google's protoc. For the LSP, Buf says it took protocompile further with a new, query-driven frontend that enables incremental compilation and finer diagnostics. As an example, Buf says its new frontend correctly flags a duplicate repeated modifier, an error protoc does not catch. To do this, Buf designed a new AST and intermediate representation instead of relying on FileDescriptorProto, which the company says is also memory-efficient enough to handle very large Buf module workspaces and flexible enough to support upcoming Protobuf Editions 2024 features.

Buf frames the LSP as completing an existing family of Protobuf tools that also includes Protobuf-ES (which Buf says is used in Chromium), Protovalidate, ConnectRPC, and the Buf Schema Registry. The company also claims that Google itself uses the protocompile frontend alongside protoc in parts of its own codebase, though it does not specify which parts. Buf describes the LSP as a first step rather than a finished product, listing several features still planned: adding imports as an automatic fix, tighter integration with buf.yaml configuration, code completion and reference lookup for custom options, automatic suggestion of field and enum numbers, and dedicated Protovalidate support including CEL syntax highlighting.

Key facts

  • Buf released what it calls the first fully-featured, production-grade LSP server for Protobuf, built into the Buf CLI.
  • It works in VSCode via the Buf extension, in Neovim via nvim-lspconfig with lspconfig.buf_ls.setup{}, and in any other LSP-capable editor by running buf lsp serve.
  • The server runs on protocompile, Buf's own compiler frontend, which Buf says is fully compliant with Protobuf and faster and more flexible than Google's protoc.
  • Buf says Google uses the protocompile frontend alongside protoc in parts of its own codebase, without specifying which parts.
  • Buf lists five features still planned but not yet shipped: automatic import fixes, tighter buf.yaml integration, code completion for custom options, automatic field and enum number suggestions, and dedicated Protovalidate/CEL syntax highlighting.

Why it matters

Protobuf has long lacked the IDE tooling that developers take for granted in other languages: go to definition, code completion, find references, and semantics-aware highlighting. Buf's LSP server closes that gap by wiring these features straight into the Buf CLI, built on protocompile, the compiler frontend Buf says is fully compliant with Protobuf and faster and more flexible than protoc. Buf presents the release as the piece that completes its existing Protobuf toolchain, alongside Protobuf-ES, Protovalidate, ConnectRPC, and the Buf Schema Registry.

Who it affects

Anyone writing Protobuf schema files in VSCode, IntelliJ, Neovim, or another LSP-capable editor. It is most immediately relevant to teams already using the Buf CLI or Buf's other tools, since the LSP is distributed as part of that same CLI. Buf also claims Google uses its protocompile compiler frontend alongside protoc in parts of Google's own codebase, though that is about the compiler, not the LSP itself.

How to use it

In VSCode, install the Buf extension; it will use an existing Buf CLI install or fetch one automatically. In Neovim, install the Buf CLI, add the nvim-lspconfig plugin, call lspconfig.buf_ls.setup{} in your config, and enable it with vim.lsp.enable('buf-lsp'). Any other LSP-supporting editor just needs to be pointed at the buf lsp serve command. The source gives no pricing or licensing terms for the LSP or the Buf CLI.

How solid is it

This is a first-party announcement from Buf, not an independently verified report. Buf describes protocompile as fully compliant with the Protobuf spec and faster and more flexible than protoc, and gives one concrete diagnostic example, catching a duplicate repeated modifier that protoc misses, but states the speed and flexibility comparison only qualitatively, without benchmark numbers. No release date or version number is given for the LSP server.

Risks and caveats

The claims of being faster, more flexible, and fully compliant than protoc come from Buf itself, with no independent benchmarks in the source. Buf explicitly says the LSP's work is not done, listing five features it has not yet built: automatic import fixes, tighter buf.yaml integration, code completion for custom options, automatic field/enum number suggestions, and dedicated Protovalidate/CEL syntax highlighting. Which specific parts of Google's codebase use protocompile is not stated.

“Our implementation isn't just fully-compliant, but it is much faster and more flexible than protoc.”

— Buf, in the announcement blog post