コンテンツにスキップ

Rigor LSP — エディタ統合

rigor lsprigortype gemにバンドルされたインプロセス言語サーバーです。stdioでLanguage Server Protocolを話し、Rigorのアナライザーをライブエディタ体験として公開します——キーストロークごとの診断、ホバーで型表示、アウトラインビュー、型認識補完。

このページはエディタに組み込むためのエントリーポイントです。設計と機能マトリックスはdocs/design/20260517-language-server.md(v1)とdocs/design/20260517-lsp-hover-completion.md(v2)にあります。パッケージング根拠はdocs/adr/19-language-server-packaging.mdにあります。

この章の内容 機能 · 前提条件 · CLI · エディタ設定 — Neovim · VS Code · Helix · Emacs / Eglot · Emacs / lsp-mode · トラブルシューティング · パフォーマンス · ステータス + ロードマップ

LSPメソッド動作
textDocument/publishDiagnosticsdidChangeのたびにプッシュ、200msデバウンス。重要度 / ルール / ソースはRigorの診断分類に直接対応。
textDocument/hover型認識Markdown。ノードクラスごとのディスパッチで、メソッド呼び出しはレシーバー型+RBSシグネチャ、定数はFQN+シングルトン型+定義パス、ローカルはナローイング(narrowing)された型+バインド位置、Refined / Differenceキャリア(carrier)には正規リファインメント(refinement、篩型とも)名(non-empty-string、…)を表示。
textDocument/completion.の後のメソッド補完(推論レシーバー型で動作)、::の後の定数パス補完。複合レシーバー(Union → メソッドの積集合、Tuple / HashShape → 祖先名前的、Refined → 基底名前的)を処理。パースリカバリーセンチネルにより、編集中のobj. / `Foo::バッファが動作する。
textDocument/documentSymbolPrism ASTからのアウトラインツリー: ネストを含むclass / module / def
workspace/didChangeWatchedFilesセッションごとのEnvironment + Cache::Storeキャッシュを無効化し、保存済みファイルが再伝播するようにする。
workspace/didChangeConfiguration同様——.rigor.yml / Gemfile.lock等を再読み込みする。

前提条件はrigorPATH上にあることだけです——rigor checkrigor type-ofがすでに使っている同じ実行ファイルです。Rigorのインストールのインストールチャンネルのいずれでも提供されます。miseが推奨です——そのshimがシェル環境を継承しないGUI起動エディタにrigorを利用可能にするからです。

rigortypeをプロジェクトのGemfileに追加しないでください。Rigorはツールであり、ライブラリではありません——スタンドアロンでインストールすることでRubyバージョンと依存関係がアプリケーションの解決から切り離されます。Rigorのインストール § 推奨 — ランタイムバージョンマネージャを参照してください。

LSPサーバーはrigor lspとして実行されます。別途gemは不要、アドオン登録も不要——rigor check / rigor type-ofと同じバイナリです。

Terminal window
rigor lsp [--transport=stdio] [--log=PATH] [--config=PATH]
  • --transport=stdio — デフォルト。v1で受け付ける唯一の値。TCP / Unixソケットトランスポートはキュー待ち。
  • --log=PATH — ワイヤーログ + サーバーデバッグをファイルに書き出す。指定しない場合、サーバー側のログはstderrに出力される。
  • --config=PATHrigor check --config=PATHのミラー。指定しない場合、Configuration.discoverがプロジェクトルートから.rigor.yml / .rigor.dist.ymlを探索する。

以下のスニペットはすべてrigor lspを直接呼び出します。rigorがエディタのPATH上にある(mise shimパス、asdf shim、またはインストールチャンネルが設定したもの——Rigorのインストールを参照)と同時に機能します。

プロジェクトのGemfilerigortypeを追加した古いプロジェクトローカルインストールを使用している場合は、rigor lspbundle exec rigor lspに置き換えてください(エディタが必要とするcwd / BUNDLE_GEMFILEも追加します)。これはレガシーフォールバックです。新しいインストールでは必要ありません。

カスタムサーバーエントリを追加します。nvim-lspconfigにはまだRigor用の組み込みプリセットがないため、手動で登録します:

local configs = require('lspconfig.configs')
local lspconfig = require('lspconfig')
if not configs.rigor then
configs.rigor = {
default_config = {
cmd = { 'rigor', 'lsp' },
filetypes = { 'ruby' },
root_dir = lspconfig.util.root_pattern('.rigor.yml', '.rigor.dist.yml', 'Gemfile', '.git'),
single_file_support = false,
},
}
end
lspconfig.rigor.setup({})

これをinit.lua(またはlua/plugins/配下)に記述します。Neovimを再起動してRigor設定済みプロジェクト内のRubyファイルを開くと、保存時に診断が表示され、Kでホバーが機能するはずです。プロジェクトのGemfilerigortypeを追加した古いインストールを使用している場合は、cmd = { 'bundle', 'exec', 'rigor', 'lsp' }に設定します。

まだ公式のVS Code拡張機能はありません。汎用LSPクライアントラッパー拡張機能を使用するか、サーバーを登録する最小限の拡張機能を作成します:

// extension.ts (minimal example)
import { workspace, ExtensionContext } from 'vscode';
import { LanguageClient, ServerOptions, TransportKind } from 'vscode-languageclient/node';
let client: LanguageClient;
export function activate(context: ExtensionContext) {
const serverOptions: ServerOptions = {
command: 'rigor',
args: ['lsp'],
transport: TransportKind.stdio,
};
client = new LanguageClient(
'rigor',
'Rigor Language Server',
serverOptions,
{ documentSelector: [{ scheme: 'file', language: 'ruby' }] }
);
client.start();
}
export function deactivate() { return client?.stop(); }

プロジェクトのGemfilerigortypeを追加した古いインストールを使用している場合は、command: 'bundle', args: ['exec', 'rigor', 'lsp']に設定します。

プライベート拡張機能として公開するか、--extensionDevelopmentPathで実行します。コミュニティが維持するマーケットプレイス拡張機能が後で登場するかもしれません。コントリビューション歓迎です。

~/.config/helix/languages.tomlに追加します:

[language-server.rigor]
command = "rigor"
args = ["lsp"]
[[language]]
name = "ruby"
language-servers = ["rigor"]

Helixはプロジェクトルート走査を通じて.rigor.ymlを自動検出します。Solargraph / ruby-lspも使用している場合は、rigorと並べて列挙します——Helixは言語ごとに複数のサーバーを実行します。プロジェクトのGemfilerigortypeを追加した古いインストールを使用している場合は、command = "bundle"args = ["exec", "rigor", "lsp"]を使用します。

(require 'eglot)
(add-to-list 'eglot-server-programs
'(ruby-mode . ("rigor" "lsp")))
;; ruby-ts-mode(Emacs 30+)の場合:
(add-to-list 'eglot-server-programs
'(ruby-ts-mode . ("rigor" "lsp")))

RubyバッファでアタッチするにはM-x eglotを実行します。プロジェクトのGemfilerigortypeを追加した古いインストールを使用している場合は、("rigor" "lsp")("bundle" "exec" "rigor" "lsp")に置き換えます。

(with-eval-after-load 'lsp-mode
(lsp-register-client
(make-lsp-client
:new-connection (lsp-stdio-connection '("rigor" "lsp"))
:activation-fn (lsp-activate-on "ruby")
:server-id 'rigor)))

プロジェクトのGemfilerigortypeを追加した古いインストールを使用している場合は、接続リストを'("bundle" "exec" "rigor" "lsp")に変更します。

サーバーは起動するが診断が表示されない

  • プロジェクトに.rigor.ymlまたは.rigor.dist.ymlがあること(またはLSPルート走査がそれを見つけること)を確認します。LSPはConfiguration.discoverを使います——rigor checkと同じロジックです。
  • LSPログ(--log=/tmp/rigor-lsp.log)でプラグイン読み込みエラーまたはRBS環境ビルドの失敗を確認します。
  • 同じプロジェクトルートからrigor check <path>を実行します。そこで機能すれば、LSPも機能するはずです。rigor checkが失敗する場合は、まずそちらを修正してください。

補完ポップアップが空

  • 補完は型がわかっているノードでのみ発火します。型がDynamic[Top]に折りたたまれるレシーバーでは補完が生成されません。rigor type-of <file>:<line>:<col>でアナライザーがレシーバーに何の型を割り当てているかを確認します。
  • 編集中のバッファサポートはベストエフォートです。パースが失敗し、かつカーソルが. / ::の直後にない場合、v1 LSPは補完を返しません。より深いリカバリーはキュー待ちです(ROADMAPの「Editor / IDE integration」セクションを参照)。

ホバーがuntypedばかり表示される

  • アナライザーがプロジェクトのRBSを読み込んでいません。.rigor.ymlに正しいsignature_paths:libraries:があることを確認します。LSPログでRBS::DuplicatedDeclarationErrorなどを確認します。

複数のLSPセッションが競合する

  • そうなるべきではありません——LSPは読み取り専用のCache::Storeを使用しており、同じプロジェクトに対する複数のプロセスがオンディスクキャッシュで競合しません。破損が見られる場合は、ログを添えてバグを報告してください。

LSP v1の設計ターゲット(ウォームセッション、5Kファイルプロジェクト、現行ラップトップ):

  • コールドスタート(initialize → 最初のプッシュ): 3秒未満。
  • didChangepublishDiagnostics: p50 < 250ms、p95 < 500ms。
  • hover: p95 < 100ms。
  • documentSymbol: p95 < 50ms。
  • メモリ定常状態: 600 MB未満。

コールドスタートはRBS環境ビルドが支配的です。ウォームスタート(rigor checkでウォームされた.rigor/cache)は1.5秒未満です。

LSP v1 + v2はv0.1.6で着地し、0.1.xラインで出荷されています。キュー待ちのフォローアップ(textDocument/signatureHelp、ハッシュキー補完、textDocument/definition、インクリメンタルdidChange同期、Ractorプールディスパッチ、codeAction / rename / semanticTokens / inlayHint)は需要駆動です。現在のキューはROADMAPの「Editor / IDE integration」セクションを参照してください。

キュー待ちの機能をリクエストするかLSPの問題を報告するには、次の情報を添えてGitHub issueを開いてください: エディタ + バージョン、Rigorバージョン(rigor version)、LSPログ(--log=PATH)、最小限の再現手順。

© 2026 TypedDuck. Licensed under CC BY-SA 4.0.