ProtobufにLSPサポートが登場、Bufが最初の本格的なLSPサーバーをリリース

Protobuf has LSP support. You're welcome

ProtobufにLSPサポートが登場、Bufが最初の本格的なLSPサーバーをリリース

Bufは、Protobuf向けの本格的なLSPサーバーを発表しました。これにより、VSCodeやNeovimなどのエディタで、定義への移動、コード補完、参照検索などの最新のIDE機能が利用可能になります。Buf CLIに統合されており、protocompileをベースにした新しいクエリ駆動フロントエンドにより、インクリメンタルコンパイルと高精度な診断を実現。Googleも採用する高速なコンパイラを基盤とし、Protobuf開発の生産性を大幅に向上させます。

Protobufは、確立されたライブラリとツールのエコシステムのおかげで、最高のスキーマ言語であると私たちは信じています。
  1. jvolkman

    「Protobufに初めてモダンなIDEサポートが登場」って、変な投稿だな。私は10年くらい前にGoogleでIntelliJのprotobufサポート[1]を作って、2021年頃からIntelliJにデフォルトで同梱されるようになった。それは「モダン」とは見なされないのかもしれない。

    [1] https://github.com/jvolkman/intellij-protobuf-editor

  2. alecthomas

    なんて傲慢な投稿だ。何年も前からProtobufのLSPが存在しているのに: https://github.com/lasorda/protobuf-language-server

  3. lacoolj

    「どういたしまして」は、企業の投稿から読むと本当に笑える。

  4. williamcotton

    依存関係を見て、既存のProtobufパーサーを使っていないことに気づいた。つまり、パーサーをゼロから再実装したということだ。おそらく既存実装のエラーリカバリ不足のせいだろうか? 今はそれ以上調べる気力がない。

    LSPを実装する際には、ランタイム用のパーサーを再利用するのが最善だが、それを適切に行うにはパーサー自体をスタンドアロンライブラリとして実装する必要がある。セマンティック分析も一緒に提供できればなお良い。

    実装のドリフトは確かに問題だ。

    でも、素晴らしいプロジェクトだと思う。ただ、自分の考えを会話に加えたかっただけだ。

  5. eterm

    ここには否定的な意見が多いが、protobufの利点はprotoファイルが手書き可能なことであり、そのためのLSPは役に立つかもしれない。

    とはいえ、proto自体はリネームのようなLSPでよくやることを推奨しないか、禁止している。

    フィールドのリネームは大きなタブーだし[編集: これは正しくない。以下の訂正を参照]、フィールドの並べ替えも同様だ。

    protoの核となる考え方は、バージョンが以前のバージョンと厳密に互換性を持つことだ。これ自体が移行の制限や課題を生むが、多くのエコシステムで無視されたり軽く扱われたりする互換性に関する良い習慣を促進する。

    ただし、再構築とバージョン互換性のチェックの両方をLLMに任せてしまうことがよくあるのは認める。

  6. gafferongames

    protobufの直接の競合ではないが、構造体のバージョン管理が不要なビデオゲーム分野で作業しているなら、「schema」という代替言語があり、C、C++、C#、Golang、Rust、JavaScriptをサポートしている。

    https://github.com/mas-bandwidth/schema

  7. gjvc

    「どういたしまして。」は、本当に嫌味な口癖だ。

  8. loicalleyne

    bufには、dynamicpbのドロップインとして使える興味深い動的protobufパーサーもある https://github.com/bufbuild/hyperpb-go

この日のほかの記事

2026-08-16