OpenCodeの設定 - LSP

提供: MochiuWiki : SUSE, EC, PCB

概要

OpenCodeのLSP (Language Server Protocol) 機能は、LLMがコードベースをより深く理解し、正確なコード操作を行うための基盤となる。
LSPを活用することにより、型チェック、エラー検出、定義へのジャンプ、参照の検索、シンボルのリネームといった高度なコード解析機能が利用可能になる。

OpenCodeは30以上のプログラミング言語に対してLSPサーバを内蔵しており、プロジェクトで使用されている言語を自動検出して適切なサーバを起動する。
ユーザが明示的に設定を行わなくても、TypeScript、Python、Rust、Go等の主要な言語であれば、ファイルを開くだけでLSP機能が有効になる。

LSPの診断情報はLLMにフィードバックされ、コードの品質向上やエラーの早期発見に貢献する。
LLMはLSPからの診断結果を参照しながらコードを生成・修正するため、型エラーや構文エラーを含むコードが生成される可能性が低くなる。

OpenCodeはLanguage Server Protocol (LSP) に対応しており、コード解析、定義ジャンプ、参照検索、リネーム等の高度なコードインテリジェンス機能を利用できる。

また、OpenCodeではカスタムLSPサーバの追加も可能であり、標準でサポートされていない言語や独自のツールチェーンを使用する場合でも、LSPの恩恵を受けることができる。

設定は、opencode.jsonファイル の lsp セクションで行い、サーバごとに環境変数、初期化オプション、ファイル拡張子のマッピング等を詳細にカスタマイズできる。


LSPとは

Language Server Protocol (LSP) は、Microsoftによって開発されたオープンなプロトコルであり、エディタやIDEと言語サーバ間の通信を標準化するものである。

LSPが解決する課題

従来、各エディタ (VS Code、Vim、Emacs等) ごとに言語サポートを実装する必要があり、同じ機能を複数のエディタで利用できるようにするには多大な労力を要していた。
LSPはこの問題を解決するために設計された。

LSP以前の状況:

  • 各エディタが独自のプラグインAPIを持つ。
    言語サポートを提供するには、エディタごとに異なる実装が必要であった。
  • 同じ言語機能を複数回実装する必要がある。
    オートコンプリート、定義ジャンプ、エラー診断等の機能を各エディタ用に個別に実装しなければならなかった。
  • 言語ツールのメンテナンスが分散する。
    複数の実装を維持する負担が大きく、品質にばらつきが生じた。


LSP導入後:

  • 言語サーバは1度だけ実装すればよい。
    任意のLSP対応エディタから利用できる共通の言語サーバを開発できる。
  • エディタはLSPクライアントを実装するだけでよい。
    様々な言語のサポートを統一的な方法で提供できる。
  • 言語コミュニティがサーバ開発に集中できる。
    高品質な言語サーバのエコシステムが発展した。


クライアント-サーバアーキテクチャ

LSPはクライアント-サーバアーキテクチャを採用している。

  • LSPクライアント (エディタ / IDE)
    ユーザインターフェースを提供し、ユーザの操作に応じて言語サーバにリクエストを送信する。
    OpenCodeはLSPクライアントとして動作する。

  • LSPサーバ (Language Server)
    特定のプログラミング言語に特化した解析エンジンである。
    コードの解析、診断、補完候補の生成等を行い、結果をクライアントに返す。


クライアントとサーバ間の通信は、JSON-RPC 2.0をベースとした標準化されたメッセージフォーマットで行われる。
通信方法としては、標準入出力 (stdio)、ソケット、パイプ等が使用できる。

LSPが提供する主な機能

下表に、LSPが標準化している主な機能を示す。

LSPの主要機能
機能 説明
診断 (Diagnostics) コード内のエラー、警告、情報を検出して報告する。
型エラー、構文エラー、リント警告等が含まれる。
定義へのジャンプ (Go to Definition) シンボルの定義場所に移動する。
変数、関数、クラス等の宣言箇所を特定できる。
参照の検索 (Find References) シンボルが参照されている全ての場所を検索する。
変数の使用箇所や関数の呼び出し元を確認できる。
シンボルの検索 (Document/Workspace Symbols) ファイル内またはワークスペース全体でシンボルを検索する。
関数、クラス、変数等を名前で検索できる。
リネーム (Rename) シンボルの名前を一括で変更する。
全ての参照箇所も同時に更新される。
ホバー (Hover) シンボルの上にカーソルを置いた際に型情報やドキュメントを表示する。
補完 (Completion) コード入力中に候補を提示する。
関数名、変数名、プロパティ等の補完が含まれる。
コードアクション (Code Actions) エラーの修正提案やリファクタリング操作を提供する。
クイックフィックスや自動修正等が含まれる。



OpenCodeでサポートされるLSPサーバ

OpenCodeは多数のプログラミング言語に対してLSPサーバを内蔵している。
これらのサーバは、対応するファイル拡張子が検出された場合に自動的に起動する。

組み込みLSPサーバ一覧

下表に、OpenCodeでサポートされるLSPサーバとその要件を示す。

組み込みLSPサーバ一覧
LSPサーバ 対応拡張子 要件
astro .astro Astroプロジェクトで自動インストール
bash .sh, .bash, .zsh, .ksh bash-language-serverが自動インストールされる。
clangd .c, .cpp, .cc, .cxx, .c++, .h, .hpp, .hh, .hxx, .h++ C/C++プロジェクトで自動インストール
csharp .cs .NET SDKがインストールされていること
clojure-lsp .clj, .cljs, .cljc, .edn clojure-lspコマンドが利用可能であること。
dart .dart dartコマンドが利用可能であること
deno .ts, .tsx, .js, .jsx, .mjs denoコマンドが利用可能であること
deno.json/deno.jsoncが自動検出される。
elixir-ls .ex, .exs elixirコマンドが利用可能であること。
eslint .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts, .vue プロジェクトにeslintの依存関係があること。
fsharp .fs, .fsi, .fsx, .fsscript .NET SDKがインストールされていること。
gleam .gleam gleamコマンドが利用可能であること。
gopls .go goコマンドが利用可能であること。
hls .hs, .lhs haskell-language-server-wrapperコマンドが利用可能であること。
jdtls .java Java SDK (バージョン21以降) がインストールされていること。
julials .jl juliaおよびLanguageServer.jlがインストールされていること。
kotlin-ls .kt, .kts Kotlinプロジェクトで自動インストール
lua-ls .lua Luaプロジェクトで自動インストール
nixd .nix nixdコマンドが利用可能であること。
ocaml-lsp .ml, .mli ocamllspコマンドが利用可能であること。
oxlint .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts, .vue, .astro, .svelte プロジェクトにoxlintの依存関係があること。
php intelephense .php PHPプロジェクトで自動インストール
prisma .prisma prismaコマンドが利用可能であること。
pyright .py, .pyi pyrightの依存関係がインストールされていること。
ruby-lsp (rubocop) .rb, .rake, .gemspec, .ru rubyおよびgemコマンドが利用可能であること。
rust .rs rust-analyzerコマンドが利用可能であること。
sourcekit-lsp .swift, .objc, .objcpp swiftがインストールされていること
MacOSではxcodeが必要
svelte .svelte Svelteプロジェクトで自動インストール
terraform .tf, .tfvars GitHub releasesから自動インストール
tinymist .typ, .typc GitHub releasesから自動インストール
typescript .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts プロジェクトにtypescriptの依存関係があること。
vue .vue Vueプロジェクトで自動インストール
yaml-ls .yaml, .yml Red Hat yaml-language-serverが自動インストール
zls .zig, .zon zigコマンドが利用可能であること。


自起動の仕組み

OpenCodeがファイルを開く時、以下に示す手順でLSPサーバが自動的に起動する。

  1. ファイルの拡張子を確認する。
  2. 拡張子に対応するLSPサーバを特定する。
  3. 対応するLSPサーバがまだ起動していない場合、自動的に起動する。


この仕組みにより、ユーザは手動でサーバを起動する必要がなく、ファイルを開くだけでLSP機能が利用可能になる。


LSPの設定方法

LSPサーバの設定は、opencode.jsonファイル の lsp セクションで行う。

設定構造

設定ファイルの基本構造を以下に示す。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "typescript": {
          "disabled": false
       }
    }
 }


設定項目一覧

各LSPサーバで設定可能な項目を以下の表に示す。

LSP設定項目一覧
プロパティ 型 説明
disabled boolean true に設定すると、そのLSPサーバを無効化する。
デフォルトは false である。
command string[] LSPサーバを起動するコマンドと引数の配列
カスタムLSPサーバを追加する場合に使用する。
extensions string[] LSPサーバが処理するファイル拡張子の配列
例: [".ts", ".tsx"]
env object サーバ起動時に設定する環境変数
キーと値のペアで指定する。
initialization object LSPサーバに送信する初期化オプション
サーバ固有の設定を渡す時に使用する。
priority number 複数のサーバが同じ拡張子を処理する場合の優先度
数値が大きいほど優先度が高い。
デフォルトは 0 である。


環境変数の設定

env プロパティを使用して、LSPサーバ起動時の環境変数を設定できる。

設定例を以下に示す。

以下に示す設定は、rust-analyzerサーバのデバッグログを有効にする。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "rust": {
          "env": {
             "RUST_LOG": "debug",
             "RUST_BACKTRACE": "1"
          }
       }
    }
 }


初期化オプションの設定

initialization プロパティを使用して、LSPサーバに初期化オプションを渡すことができる。
これらのオプションはLSPの initialize リクエスト時にサーバに送信される。

TypeScriptサーバの設定例を以下に示す。

以下に示す設定は、TypeScriptのインポートパスを相対パス形式にし、package.jsonからの自動インポートを有効にする。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "typescript": {
          "initialization": {
             "preferences": {
                "importModuleSpecifierPreference": "relative",
                "includePackageJsonAutoImports": "on"
             }
          }
       }
    }
 }


LSPサーバの無効化

特定のLSPサーバを無効化するには、disabled プロパティを true に設定する。

  • 特定のサーバを無効化する例 
     {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "typescript": {
          "disabled": true
       }
    }
 }

  • 全てのLSPサーバを一括で無効化するには、lsp プロパティ全体を false に設定する。 
     {
    "$schema": "https://opencode.ai/config.json",
    "lsp": false
 }


カスタムLSPサーバの追加

OpenCodeに標準で含まれていない言語やツール用に、カスタムLSPサーバを追加できる。

カスタムサーバを追加するには、command と extensions を指定する。

カスタムLSPサーバの追加例を以下に示す。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "custom-lsp": {
          "command": ["custom-lsp-server", "--stdio"],
          "extensions": [".custom", ".cust"]
       }
    }
 }


カスタムLSPサーバを追加する時の注意点を以下に示す。

  • command には、サーバがstdioモードで動作するように --stdio フラグを含める必要がある。
  • extensions には、先頭にドットを含めた拡張子を指定する。
    例: [".ts"] (正)、["ts"] (誤)
  • 指定したコマンドがシステムの環境変数 PATH に含まれていることを確認する。


優先度の設定

複数のLSPサーバが同じファイル拡張子を処理する場合、priority で優先順位を制御できる。
数値が大きいほど優先度が高く、優先的に使用される。

優先度設定の例を以下に示す。

以下の例では、TypeScriptファイルに対して、typescript-language-serverが優先的に使用される。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "typescript-language-server": {
          "command": ["typescript-language-server", "--stdio"],
          "extensions": [".ts", ".tsx"],
          "priority": 10
       },
       "eslint": {
          "command": ["vscode-eslint-language-server", "--stdio"],
          "extensions": [".ts", ".tsx", ".js", ".jsx"],
          "priority": 5
       }
    }
 }



利用可能なLSPツール

OpenCodeは、LSP機能を利用するための複数のツールを提供している。
これらのツールを使用することにより、コード解析、ナビゲーション、リファクタリング等の操作をプログラム的に実行できる。

lsp_diagnostics

ファイルまたはプロジェクト全体の診断情報 (エラー、警告、ヒント) を取得するツールである。

パラメータ
lsp_diagnosticsパラメータ
パラメータ 型 必須 説明
filePath string はい 診断を取得するファイルのパス。
絶対パスまたは相対パスで指定する。
severity string いいえ 取得する診断の重要度をフィルタリングする。
値: "error", "warning", "information", "hint", "all"
デフォルト: "all"


使用例
 // 特定ファイルの全ての診断を取得
 lsp_diagnostics({ filePath: "/path/to/file.ts" })
 
 // エラーのみを取得
 lsp_diagnostics({ filePath: "/path/to/file.ts", severity: "error" })


ユースケース
  • コード変更前にエラーの有無を確認する。
    変更を加える前に現在のエラー状態を把握し、変更による影響を評価できる。

  • ビルド前に型チェックを行う。
    ビルドコマンドを実行する前に、型エラーがないことを確認できる。

  • コードレビュー時の品質チェック
    変更されたファイルの診断情報を確認し、潜在的な問題を特定できる。


lsp_goto_definition

シンボルの定義場所にジャンプするツールである。
変数、関数、クラス等の宣言箇所を特定できる。

パラメータ
lsp_goto_definitionパラメータ
パラメータ 型 必須 説明
filePath string はい 対象ファイルのパス
line number はい シンボルの行番号 (1始まり)
character number はい シンボルの列番号 (0始まり)


使用例
 // 変数の定義場所を取得
 lsp_goto_definition({
    filePath: "/path/to/file.ts",
    line: 10,
    character: 15
 })


ユースケース
  • 関数の実装を確認する。
    関数呼び出し箇所から定義に移動し、実装の詳細を確認できる。

  • インポート元のモジュールを特定する。
    インポートされたシンボルの元の定義場所を特定できる。<

  • 型定義の確認
    使用されている型の定義を確認し、型の構造を理解できる。


lsp_find_references

シンボルが参照されている全ての場所を検索するツールである。
ワークスペース全体を対象に検索を行う。

パラメータ
lsp_find_referencesパラメータ
パラメータ 型 必須 説明
filePath string はい 対象ファイルのパス
line number はい シンボルの行番号 (1始まり)
character number はい シンボルの列番号 (0始まり)
includeDeclaration boolean いいえ 定義箇所も結果に含めるかどうか。
デフォルト: true


使用例
 // 関数の全ての使用箇所を検索
 lsp_find_references({
    filePath: "/path/to/file.ts",
    line: 5,
    character: 10,
    includeDeclaration: true
 })


ユースケース
  • リファクタリング前の影響範囲調査
    変数や関数を変更する前に、影響を受ける箇所を全て把握できる。

  • 未使用コードの検出
    参照が1つも見つからない場合、そのシンボルが未使用である可能性が高い。

  • 依存関係の分析
    特定のモジュールや関数がどこで使用されているかを確認できる。


lsp_symbols

ファイルまたはワークスペース内のシンボルを検索するツールである。
ドキュメントスコープとワークスペーススコープの2つのモードを持つ。

パラメータ
lsp_symbolsパラメータ
パラメータ 型 必須 説明
filePath string はい 対象ファイルのパス
scope string いいえ 検索スコープ
値: "document" (ファイル内), "workspace" (プロジェクト全体)
デフォルト: "document"
query string いいえ 検索クエリ
シンボル名の一部を指定してフィルタリングできる。
limit number いいえ 返される結果の最大数


使用例
 // ファイル内のシンボル一覧を取得
 lsp_symbols({
    filePath: "/path/to/file.ts",
    scope: "document"
 })
 
 // ワークスペース全体から特定のクラスを検索
 lsp_symbols({
    filePath: "/path/to/file.ts",
    scope: "workspace",
    query: "UserService"
 })


ユースケース
  • ファイル構造の把握
    ファイル内の関数、クラス、変数の一覧を確認し、コードの全体像を把握できる。

  • プロジェクト全体のシンボル検索
    特定の名前を持つクラスや関数をプロジェクト全体から検索できる。

  • APIの探索
    公開されている関数やクラスを素早く見つけられる。


lsp_prepare_rename

シンボルのリネームが可能かどうかを確認するツールである。
実際のリネームを行う前に、そのシンボルがリネーム可能かどうかを検証するために使用する。

パラメータ
lsp_prepare_renameパラメータ
パラメータ 型 必須 説明
filePath string はい 対象ファイルのパス
line number はい シンボルの行番号 (1始まり)
character number はい シンボルの列番号 (0始まり)


使用例
 // リネームが可能か確認
 const result = lsp_prepare_rename({
    filePath: "/path/to/file.ts",
    line: 10,
    character: 5
 })
 
 if (result) {
    // リネームが可能
    lsp_rename({ ... })
 }


ユースケース
  • リネーム前の検証
    実際にリネームを実行する前に、そのシンボルがリネーム可能かどうかを確認できる。

  • 編集可能範囲の特定
    リネーム時にどの範囲が編集されるかを事前に把握できる。


lsp_rename

シンボルの名前を一括で変更するツールである。
ワークスペース内の全ての参照箇所も同時に更新される。

パラメータ
lsp_renameパラメータ
パラメータ 型 必須 説明
filePath string はい 対象ファイルのパス
line number はい シンボルの行番号 (1始まり)
character number はい シンボルの列番号 (0始まり)
newName string はい 新しいシンボル名


使用例
 // 変数名を変更
 lsp_rename({
    filePath: "/path/to/file.ts",
    line: 10,
    character: 5,
    newName: "newVariableName"
 })


ユースケース
  • 変数名の変更
    意味不明な変数名をより適切な名前に変更できる。

  • 関数名のリファクタリング
    関数の目的に合った名前に変更し、ソースコードの可読性を向上できる。

  • クラス名の変更
    クラスの役割をより正確に表す名前に変更できる。


リネームの注意点
  • リネームはプロジェクト全体に影響する
    ワークスペース内の全ての参照箇所が更新されるため、変更前に影響範囲を確認することが推奨される。

  • 一部のシンボルはリネームできない
    標準ライブラリのシンボルや外部パッケージのシンボルはリネームできない場合がある。

  • lsp_prepare_rename で事前確認を推奨
    リネームを実行する前に、lsp_prepare_rename でリネームが可能かどうかを確認することを推奨する。



設定例

言語別のLSPの設定例を以下に示す。

TypeScript / JavaScript

TypeScriptおよびJavaScriptプロジェクトの設定例を以下に示す。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "typescript": {
          "initialization": {
             "preferences": {
                "importModuleSpecifierPreference": "relative",
                "includePackageJsonAutoImports": "on"
             }
          }
       }
    }
 }


Python

Pythonプロジェクト (pyright使用) の設定例を以下に示す。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "pyright": {
          "env": {
             "PYTHONPATH": "./src"
          }
       }
    }
 }


Rust

Rustプロジェクト (rust-analyzer使用) の設定例を以下に示す。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "rust": {
          "initialization": {
             "checkOnSave": {
                "command": "clippy"
             },
             "cargo": {
                "features": "all"
             }
          }
       }
    }
 }


複数サーバの併用

TypeScriptファイルに対して、typescriptサーバとeslintサーバを併用する設定例を以下に示す。

以下に示す設定では、typescriptサーバが主要なソースコード解析を担当し、eslintサーバがリント機能を提供する。

 {
    "$schema": "https://opencode.ai/config.json",
    "lsp": {
       "typescript": {
          "extensions": [".ts", ".tsx", ".js", ".jsx"],
          "priority": 10
       },
       "eslint": {
          "extensions": [".ts", ".tsx", ".js", ".jsx"],
          "priority": 5
       }
    }
 }



LSPの動作原理

ファイルオープン時の処理フロー

ユーザがファイルを開いた時、OpenCodeは以下に示す順番で処理を実行する。

  1. ファイル拡張子の確認
    開かれたファイルの拡張子を抽出する。

  2. LSPサーバのマッチング
    拡張子に対応するLSPサーバを検索する。
    複数のサーバが一致する場合は、優先度が最も高いサーバを選択する。

  3. サーバの起動確認
    選択されたLSPサーバが既に起動しているか確認する。
    起動していない場合は、新たにサーバプロセスを起動する。

  4. ファイルの同期
    ファイルの内容をLSPサーバに同期する。
    サーバは内容を解析して、診断情報を生成する。

  5. 診断情報の受信
    LSPサーバからの診断情報を受信し、OpenCodeの内部状態を更新する。
    診断情報はLLMにフィードバックされる。


LSP通信の流れ

LSPクライアントとサーバ間の通信は、JSON-RPC 2.0フォーマットで行われる。

主な通信パターンを以下に示す。

  • リクエスト-レスポンス
    クライアントがリクエストを送信して、サーバがレスポンスを返す。
    例: 定義へのジャンプ、参照の検索

  • 通知
    一方向のメッセージ
    応答を期待しない。
    例: ファイルの変更通知、設定の更新

  • サーバからのプッシュ
    サーバからクライアントへの能動的な通知
    例: 診断情報の更新、ログメッセージ


診断情報の活用

LSPサーバから提供される診断情報は、以下のように活用される。

  • LLMへのフィードバック
    診断情報はLLMに提供され、コード生成や修正の品質向上に活用される。

  • エラーの早期発見
    コード編集中にリアルタイムでエラーが検出され、即座にフィードバックが提供される。

  • 品質の可視化
    エラーや警告の数を把握し、コード品質の現状を確認できる。



推奨される事柄

適切な優先度設定

複数のLSPサーバが同じファイル拡張子を処理する場合、適切な優先度を設定することが重要である。

推奨される優先度設定のガイドラインを以下に示す。

  • プライマリ言語サーバ : 優先度 10
    メインのソースコード解析を担当するサーバには高い優先度を設定する。
    例: TypeScriptプロジェクトでのtypescriptサーバ

  • リンター / フォーマッター : 優先度 5
    リント機能を提供するサーバには中程度の優先度を設定する。
    例: eslintサーバ

  • 補助的なサーバ : 優先度 1
    補助的な機能を提供するサーバには低い優先度を設定する。
    例: prettierサーバ


不要なサーバの無効化

使用しないLSPサーバは無効化することにより、リソースの節約とパフォーマンスの向上が期待できる。

無効化が推奨されるケースを以下に示す。

  • プロジェクトで使用しない言語のサーバ
    例: PythonプロジェクトでTypeScriptサーバを使用しない場合

  • 競合する機能を持つサーバ
    複数のサーバが同じ機能を提供し、競合が発生する場合

  • パフォーマンスに問題があるサーバ
    特定のサーバが原因で動作が遅くなる場合


環境変数の設定

LSPサーバが必要とする環境変数は、opencode.jsonファイル で明示的に設定することを推奨する。

設定が推奨される環境変数の例を以下に示す。

  • PYTHONPATH (Pythonサーバ)
    モジュールの検索パスを明示的に指定する。

  • RUST_LOG (Rustサーバ)
    デバッグ時のログレベルを制御する。

  • JAVA_HOME (Javaサーバ)
    Javaのインストール場所を明示する。


プロジェクト固有の設定

LSPの設定はプロジェクトごとに異なる場合が多いため、プロジェクトルートの opencode.jsonファイル に設定を記述することを推奨する。

プロジェクト固有の設定のメリットを以下に示す。

  • チーム間での設定共有
    バージョン管理システムを通じて設定を共有できる。

  • プロジェクトごとの最適化
    各プロジェクトの特性に合わせた設定が可能である。

  • 設定の分離
    グローバル設定とプロジェクト設定を分離できる。



トラブルシューティング

LSPサーバが起動しない

コマンドの確認

指定したコマンドがシステムの環境変数 PATH に含まれているか確認する。

# コマンドが存在するか確認
which typescript-language-server

# バージョンを確認
typescript-language-server --version


要件の確認

LSPサーバの要件を満たしているか確認する。

  • 必要なSDKがインストールされているか
    例: csharpサーバには.NET SDKが必要

  • 必要な依存関係がプロジェクトに存在するか
    例: typescriptサーバにはtypescriptパッケージが必要


stdioモードの確認

カスタムLSPサーバを追加する場合、サーバがstdioモードで動作することを確認する。
多くのLSPサーバは --stdio フラグでstdioモードを有効にできる。

LSPサーバが応答しない

ファイル拡張子の設定確認

extensions の設定が正しいか確認する。

 {
    "lsp": {
       "typescript": {
          "extensions": [".ts", ".tsx"]
       }
    }
 }


優先度の確認

複数のサーバが同じ拡張子を処理する場合、優先度が適切に設定されているか確認する。

サーバの無効化状態の確認

サーバが誤って無効化されていないか確認する。

パフォーマンスの問題

LSPの動作が遅い場合、以下に示す対策を検討する。

不要なサーバの無効化

使用しないLSPサーバを無効化してリソースを節約する。

 {
    "lsp": {
       "unused-server": {
          "disabled": true
       }
    }
 }


大規模プロジェクトでの対策

大規模プロジェクトでは、以下の対策が有効な場合がある。

  • ファイル監視の除外設定
    watcher.ignore でノイズの多いディレクトリを除外する。

  • 初期化オプションの調整
    サーバ固有の設定でインデックス範囲を制限する。


診断情報が表示されない

LSPサーバの状態確認

サーバが正常に起動しているか確認する。

ファイルの同期状態確認

ファイルがLSPサーバに正しく同期されているか確認する。
ファイルを保存して再読み込みすることで、再同期を試行できる。

サーバ設定の確認

診断機能が有効になっているか、サーバの設定を確認する。
一部のサーバでは、診断機能を明示的に有効にする必要がある場合がある。


PHP Intelephenseの特別な設定

PHP Intelephenseは、ライセンスキーを設定することでプレミアム機能を利用できる。

ライセンスキーの設定方法

ライセンスキーは、以下に示すパスにテキストファイルとして配置する。

  • MacOS / Linux
    ~/intelephense/license.txt

  • Windows
    %USERPROFILE%/intelephense/license.txt


ファイルにはライセンスキーのみを記述し、他の内容を含めないように注意する。


参考リンク



「https://mochiu.net/index.php?title=OpenCodeの設定_-_LSP&oldid=14504」から取得