If you've ever worked with Protocol Buffers in a serious codebase, you know the pain. Every other language has rich IDE support: go-to-definition, autocompletion, find-references, syntax highlighting that actually understands your code. Protobuf? You got syntax highlighting if you were lucky.
Buf just changed that. They shipped the first fully-featured, production-grade LSP server for Protobuf, and it's available now.
What Is LSP and Why Does Protobuf Need It?
The Language Server Protocol, originally created by Microsoft for VS Code, has become the standard API for integrating language support into any IDE or text editor. An LSP server provides the smarts that power go-to-definition, code completion, finding references, and semantics-aware syntax highlighting.
LSP is why your IDE knows what methods exist on a class, why it can jump to a function definition across files, why it can rename a variable everywhere it's used. Every major language has an LSP implementation. Python has pyright. Rust has rust-analyzer. Go has gopls.
Protobuf didn't have one. Until now.
Why This Matters for Schema-Driven Development
Protobuf is the backbone of gRPC, which powers microservice communication at Google, Netflix, Square, and countless other companies. When your entire API contract is defined in .proto files, the lack of IDE support isn't just an inconvenience, it's a productivity drain.
Without LSP, working with Protobuf means:
- No autocomplete. You type field names from memory or by scrolling through the file.
- No go-to-definition. Want to see what a message type looks like? Open the file and search.
- No find-references. Need to know which messages reference a particular type? Good luck with grep.
- No semantic highlighting. Your IDE highlights strings and comments but has no idea which identifiers are types, fields, or enums.
With Buf's LSP server, all of this works. You can hover over a type name and see its definition. You can rename a field and have it update everywhere. You can jump between imported files seamlessly.
The Technical Challenge
Implementing LSP for Protobuf isn't trivial. Protobuf imports can reference files from different repositories through the Buf Schema Registry. A type defined in one organization's schema might be used in another's. The LSP server needs to resolve these cross-repository references, understand Protobuf's import system, and handle the full type system including maps, oneofs, and nested types.
Buf was in a unique position to build this. They already maintain the Buf CLI, the Buf Schema Registry, and widely-used open source projects like ConnectRPC and Protovalidate. They know Protobuf's grammar, its edge cases, and its ecosystem better than almost anyone.
What This Means for the Ecosystem
Protobuf has been growing as a serialization format, not just for gRPC but for data pipelines, configuration, and storage. The lack of proper tooling has been a persistent complaint from developers evaluating it against alternatives like JSON Schema or Avro.
With proper LSP support, the developer experience gap closes significantly. New developers can explore .proto files with the same IDE features they expect from any other language. Experienced developers can refactor schemas with confidence, knowing the LSP server will catch broken references.
How to Get It
The LSP server is part of the Buf CLI. If you're already using Buf, you likely have it or can update to get it. It integrates with VS Code, Neovim, IntelliJ, and any other editor that supports LSP, which is essentially all of them.
For teams that have been waiting for Protobuf tooling to mature, this is the milestone they've been waiting for. Schema development just got a lot more ergonomic.
And if you've been on the fence about adopting Protobuf because of tooling concerns, that fence just got a lot lower.
Top comments (0)