Ruby: 手作りVS Code拡張をアンインストールしてRuby LSPアドオンに乗り換えました（翻訳）

Ruby: 手作りVS Code拡張をアンインストールしてRuby LSPアドオンに乗り換えました（翻訳）

1年以上前に、Ruby LSP用のStandard Ruby（Standard）アドオンをリリースしないかとVini Stockから誘われ、ShopifyのRuby DXチームの多大な協力を得て（#630）、ついにリリースにこぎつけました。実は、standard gemのバージョンが1.39.1以上であれば、Ruby LSPの新しいアドオンとして既に組み込まれています。

Ruby LSPは、言語サーバー（language server）をサポートする任意のエディタで利用できますが、設定方法はエディタごとにまちまちです。VS Codeは比較的広く使われているので、VS Code向けのセットアップ方法を追加してありますが、Ruby LSPユーザーなら、ほとんどの場合Standard を以下の設定でlinterおよびフォーマットとして指定するだけで済みます。

"[ruby]": {
  "editor.defaultFormatter": "Shopify.ruby-lsp"
},
"rubyLsp.formatter": "standard",
"rubyLsp.linters": [
  "standard"
]

このコンフィグを1週間と少し試してみた結果、昨年初頭に公開した手作りの特製VS Code拡張をついにアンインストールするときが来たと判断しました。

StandardのREADMEも更新して、新しいRuby LSPアドオンの方が手作りの組み込み言語サーバーより優秀である理由についての説明を追加しました。
手短に言うと、Ruby LSPアドオンは従来の組み込み言語サーバーでサポートしていなかったpull diagnosticsとcode actionsをサポートしています。

当面の間、Standard Rubyの組み込み言語サーバーに加えて既存のVS Code拡張のサポートも継続しますが、今後Ruby LSPアドオンが「無料で」提供されるようになれば、新機能に重点的な投資を行う意味は薄れてきます。

🔗 乗り換える理由

理由は3つあります。

1. 機能。
   Ruby LSPは、フル機能かつ高性能な言語サーバーを手作りする方法を考えるための苦労を巻き取ってくれます。手作りする場合の問題は、基本的なstdioサーバーを実装することではなく、「ログ出力」「デバッグ」「テストハーネス」といった独自のユーティリティを作るのが極めて面倒だという点です。
   ライブラリ作者は、Ruby LSPにアドオンとしてプラグインすることで、よりシンプルな高レベルAPIと統合し、LSPに実装されている機能や公開されているユーティリティをすべて活用できるようになり、面倒な機能を再発明する必要がなくなります（たとえばプロジェクトスコープのコードインデックス化機能、Ruby LSPの十分テスト済みの堅牢なインデックスを活用できます）。

2. 重複。
   RuboCopのメンテナーであるKoichi Itoは、RubyKaigi 2024で私が想像できる限りで最もアツい言語サーバー関連のプレゼンテーションを行いました。その中で、「すべてのライブラリ作者が同じような基本実装を手作りしている一方で、ツール機能を強化する緊密に統合された独自の言語サーバーも求められている」という相矛盾する無駄について論じていました。Standard Rubyの場合は、この2方向から圧迫されています。
   Ruby LSPアドオンの場合は、ライブラリ作者ごとに独自のVS Code拡張を公開するよりも便利な「バッテリー内蔵」ソリューションです。他方、独自のカスタムLSPコードをやめてRuboCop組み込み言語サーバーに委譲すれば、自分たちだけでは提供できない機能を開放できます。

3. メンテナンス性。
   私がこんなものを楽しくメンテナンスしているとお思いですか？

🔗 Ruby LSPアドオンに兜を脱いだ

まあ中期的に考えれば、Ruby LSPとRuboCopが言語サーバーを提供する方が、Standard Ruby単体が独自に言語サーバーを提供するよりも適した位置にあるでしょうね。Will Leinweberの実装のおかげで、私たちStandard Ruby勢が一番乗りする見込みがあるかもしれませんが、私たちの言語サーバーが他の言語サーバーより優秀であることを確かめるために空き時間を費やしたところで、私は何ひとつ得しません。
そして長期的には統合がさらに進み、ひいてはおそらくRuby LSPが優勢になるでしょう。
しかし最終的には、それらが「言語サーバー」と呼ばれる理由が見えてくるでしょう。すなわち、Rubyに何らかの言語サーバー（および任意のコードを手軽にプラグインできるAPI）が組み込まれるようになれば、Rubyが他の言語との競争で優位に立てることが証明されるとともに、開発エクスペリエンスを段階的に向上させるのに有用な新しいツールが使えるようになる可能性があります。

人間レベルで言えば、自分の成果を手放す可能性を、失敗の気持ちに結びつけないことが大事だと思っています。コードは資産ではなく負債です。コードを減らしても大丈夫な状況になると、コードを削除したときに何とも言えない安らぎを感じます。競争相手の方法がメリットで上回ったときに、デフォルトの反応が安らぎでないときは（そうなることは想像がつきます: コード作者のプライドは重要です）、こうしたマインドセットを身につけることをおすすめします。解決する価値のある問題はいくらでもあるのですから、誤ったソリューションを弁護するために1分たりとも無駄にはできません。

ともかく、ぜひ皆さんにもStandard RubyとRuby LSPをお試しいただき、結果をメールでお知らせください。少なくとも何かを打ち破れなければ物足りません。

関連記事

Ruby LSPアドオンシステムの概要（翻訳）