Protobuf finally gets a production-grade LSP server
Protobuf has LSP support. You're welcome
Buf has released the first fully-featured LSP server for Protobuf, bringing modern IDE support to the schema language for the first time. The server, bundled with the Buf CLI, offers features like go-to-definition, code completion, and incremental compilation. It's available for VSCode and Neovim, with plans for more features like automatic imports and Protovalidate support.
We don’t want to overstate our own work, but this is a game-changer for Protobuf development: Protobuf now has modern IDE support for the first time, all powered by the Buf CLI.
- jvolkman
> Protobuf now has modern IDE support for the first time
Weird post. I built IntelliJ protobuf support [1] while at Google like 10 years ago, and it started shipping by default with IntelliJ in ~2021. Maybe that's not considered "modern".
- alecthomas
What an oddly arrogant post, there's been a Protobuf LSP available for years: https://github.com/lasorda/protobuf-language-server
- lacoolj
"You're welcome" is absolutely hilarious to read from a company post.
- williamcotton
I looked at the dependencies and noticed that it wasn’t using an existing Protobuf parser which means they reimplemented the parser from scratch. Perhaps due to a lack of error recovery in the existing implementations? I don’t have the energy right now for further inspection.
It is definitely best to reuse the parser for the runtime when implementing an LSP but to do so properly means implementing the parser itself as a standalone library. Even better is shipping the semantic analysis as well!
Implementation drift is definitely an issue.
But great project anyways, just wanted to put my thoughts on the matter into the conversation!
- eterm
Lots of naysayers here, but an advantage of protobuf is that proto files are hand-writeable, and therefore having an LSP for that could be useful.
That said, proto itself dissuades or forbids the kind of common things you might do with a LSP, such as renaming.
Renaming fields is a big no-no [edit: this isn't true, see corrections below], as is doing things like re-ordering fields.
A core idea of proto is that versions are strictly compatible with with previous versions. This itself has limitations and challenges for migrations, but encourages good practice about compatibility that usually gets ignored or hand-waved away in most ecosystems.
I accept however that it's often easy to offload both the re-structuring and the checking of version compatibility to an LLM and let them go at it.
- gjvc
"You're welcome." is such a smug verbal tic.
- nullbio
Protobuf getting LSP support before Codex implements LSPs is wild.
- PufPufPuf
Buf does great work at fixing Protobuf to the point of being just barely usable. A godsend if you're stuck with Protobuf/gRPC on a legacy project.