高度な機能¶

これらの機能は、ReScript 開発のための追加の生産性向上ツールを提供します。

モノレポ対応¶

rescript.json（または bsconfig.json）がワークスペースのルート直下に無い場合でも、プラグインは ReScript プロジェクトを認識します。pnpm / npm / yarn のワークスペース構成でサブパッケージ配下に ReScript が存在するケースが典型例です。

自動検出パイプライン¶

プラグインは次のレイヤーを順番に走査し、最初に 1 件以上のパッケージルートを返したレイヤーで打ち切ります。

手動上書き — Settings > Languages & Frameworks > ReScript > Project package roots で指定したエントリ。
ワークスペースファイル — pnpm-workspace.yaml の packages:、続いて package.json の workspaces（配列形式）および workspaces.packages（yarn classic のオブジェクト形式）。
深さ制限スキャン — 最大 4 階層までを再帰的に走査します。node_modules、.git、build、dist、.pnpm などの非ソースディレクトリはスキップします。
親方向走査 — サブディレクトリを直接開いた場合に祖先の ReScript 設定を拾うためのフォールバック。

検出結果は monorepo 対応のすべての挙動で共有されます: 設定不足 Inspection、コンパイルステータスウィジェット、LSP 起動時の通知、node_modules/.bin/rescript-language-server の LSP バイナリ探索。

手動上書き¶

Settings > Languages & Frameworks > ReScript を開き、Project package roots にプロジェクトベースディレクトリからの相対パスを 1 行 1 つ列挙します。

packages/core
packages/server

フィールドを空にすると自動検出に戻ります。存在しないパスや ReScript 設定ファイルを含まないエントリは暗黙に無視されるため、保存をブロックされることなくリストを編集できます。

制限事項¶

!否定 glob エントリやブレース展開は v1 ではサポートしません。
深さ制限フォールバックは 4 階層までです。それより深いレイアウトは手動上書きかワークスペースファイルで宣言してください。
LSP サーバー自体はワークスペース root を作業ディレクトリとして受け取ります。ファイル単位のプロジェクト解決は @rescript/language-server 側に委譲されます。

Code Lens¶

LSP Required

Code Lens は、推論された型シグネチャを関数定義の上にインライン注釈として表示します。各識別子にホバーすることなく、コンパイラが推論した型を即座に確認できます。

// (int, int) => int        <-- Code Lens annotation
let add = (a, b) => a + b

// string => string         <-- Code Lens annotation
let greet = (name) => `Hello, ${name}!`

// (array<'a>, 'a => 'b) => array<'b>   <-- Code Lens annotation
let mapArray = (arr, fn) => arr->Array.map(fn)

仕組み¶

Code Lens は LSP の textDocument/codeLens プロトコルを利用し、IntelliJ の CodeVision API に橋渡しされます:

プラグインは現在のファイルに対して rescript-language-server に codeLens リクエストを送信します
Language Server は Code Lens エントリの配列を返します。各エントリには行位置と、推論された型文字列を含む command.title が含まれます
プラグインは各エントリを TextCodeVisionEntry にマッピングし、エディタ内の対応する行の上に配置します

Code Lens の注釈は 表示専用 です --- 推論された型を表示しますが、クリックしてもアクションは実行されません。

設定¶

Code Lens の切り替え: Settings > Editor > Inlay Hints > Code Vision を開き、リストから "ReScript Type Annotations" を見つけてください
アンカー位置: 注釈は常に関数定義行の上に表示されます（トップアンカー）
ファイルタイプ: Code Lens は .res ファイルにのみ表示され、.resi インターフェースファイルには表示されません（インターフェースファイルには既に明示的な型宣言が含まれているため）

要件¶

Code Lens を使用するには Language Server が実行されている必要があります。LSP サーバーに接続されていない場合、注釈は表示されません。また、Language Server が型情報を利用できるように、プロジェクトを少なくとも一度ビルドする必要があります。

Code Lens は関数定義の直上に推論された型シグネチャを表示するため、明示的なアノテーションを追加したり各識別子にホバーしたりせずに型を確認できます。

参考

シンタックスハイライトでは、Code Lens の型注釈を支えるセマンティックトークンシステムについて説明しています。

コンパイル済み JavaScript プレビュー¶

Native

現在アクティブな ReScript ファイルのコンパイル済み JavaScript 出力を表示する専用ツールウィンドウです。ReScript ソースとその JavaScript コンパイル結果を並べて表示できます。

開き方: View > Tool Windows > Compiled JS Preview

自動更新の動作¶

プレビューパネルは以下の 2 つの状況で自動的に更新されます:

アクティブファイルの切り替え --- エディタタブを切り替えると、新しくフォーカスされた .res または .resi ファイルのコンパイル済み JS を表示するようにプレビューが更新されます
コンパイル成功時 --- ReScript コンパイラのビルドが成功すると（rescript/compilationStatus LSP 通知で検出）、プレビューがリロードされ最新のコンパイル出力が表示されます

分割表示のセットアップ¶

並列表示のワークフロー:

エディタで .res ファイルを開きます
View > Tool Windows > Compiled JS Preview を開きます
ツールウィンドウのタブをエディタの右側にドラッグして、垂直分割を作成します
ReScript コードを編集・保存すると、右側の JavaScript 出力が自動的に更新されます

ユースケース¶

コンパイル出力の理解 --- ReScript の構文（パターンマッチング、パイプ演算子、バリアント）が JavaScript にどのように変換されるかを確認できます
デバッグ --- ランタイムの動作を調査する際に、ソースと出力を比較できます
パフォーマンスレビュー --- 生成された JavaScript が効率的で期待通りであることを確認できます
学習 --- ReScript の機能が JavaScript のイディオムにどのように対応するかを理解できます

コンパイル済み JS ファイルが見つからない場合（例: プロジェクトがビルドされていない場合）、パネルにプロジェクトを先にビルドするよう促すメッセージが表示されます。

コンパイル済み JS プレビューは ReScript と JavaScript 出力のライブ並列ビューを提供し、IDE を離れることなくコンパイル結果の理解、ランタイム問題のデバッグ、パフォーマンス特性の確認に役立ちます。

モジュール階層¶

Native

任意の ReScript モジュールのモジュール構造と依存関係を表示します。

開き方: モジュール上にカーソルを置き、Navigate > Type Hierarchy (Ctrl+H) を使用します

2 つの表示モード¶

階層ブラウザには 2 つの異なるツリービューがあります:

1. モジュールのネスト

ファイル内のネストされたモジュール構造を表示します。これがデフォルトのビューです。モジュールが階層的にどのように構成されているかを表示します:

// File: Utils.res
module String = {          // <-- Root
  module Validate = {      //     child of String
    let isEmail = ...
    let isUrl = ...
  }
  module Format = {        //     child of String
    let capitalize = ...
    let truncate = ...
  }
}
module Number = {          // <-- Root
  module Parse = {         //     child of Number
    let toInt = ...
  }
}

階層ビューでは、以下のように表示されます:

Utils.res
  +-- String
  |     +-- Validate
  |     +-- Format
  +-- Number
        +-- Parse

2. モジュールの依存関係

open および include ステートメントで参照されるモジュールを表示します。このビューは、現在のファイルの外部依存関係を明らかにします:

open Belt
open Belt.Array
include SharedUtils

let process = (arr) => arr->Array.map(x => x + 1)

依存関係ビューには以下が表示されます:

MyModule.res
  +-- open Belt
  +-- open Belt.Array
  +-- include SharedUtils

ナビゲーション¶

階層ビューは以下をサポートしています:

ツールバーボタンによる Module Nesting と Module Dependencies のビュー切り替え
モジュール名によるアルファベット順のソート
ノードをダブルクリックしてソースモジュールに移動

モジュール階層ビューはファイルの内部構造と外部依存関係の両方を明らかにし、open や include 文を手動で読むことなくモジュールの構成と相互接続を容易に理解できます。

Inlay Hints¶

LSP Required

Language Server は、変数やパラメータの横に推論された型をインラインヒントとして表示します。明示的な型注釈がなくてもコードを理解しやすくなります。

let x /* : int */ = 42
let name /* : string */ = "ReScript"
let items /* : array<int> */ = [1, 2, 3]

let greet = (name /* : string */, age /* : int */) => {
  `${name} is ${age->Int.toString} years old`
}

let result /* : option<string> */ = list->List.head

設定¶

Settings > Editor > Inlay Hints > ReScript に移動してInlay Hints を設定します:

有効化/無効化 --- ReScript ファイル全体の Inlay Hints を切り替えます
Inlay Hints は Language Server によって提供されます。利用可能かどうかは LSP サーバーが接続されているかどうか、およびプロジェクトがビルドされているかどうかに依存します

Code Lens との違い¶

Code Lens は関数定義行の上に完全な関数シグネチャを表示します
Inlay Hints は各変数やパラメータの横に個別の型注釈を インラインで 表示します

どちらの機能も Language Server に依存していますが、異なる場所で異なる粒度の情報を表示します。

PPX アノテーションヒント¶

PPX アノテーションヒントは、各 @ 属性が何を生成またはバインドするかのインライン説明を表示し、ドキュメントを参照せずに PPX の動作を理解するのに役立ちます。

@react.component           // generates React.createElement
let make = (~name: string) => {
  <div> {React.string(name)} </div>
}

@module("fs")              // binds to JS module "fs"
external readFile: string => promise<string> = "readFile"

@genType                   // generates .gen.tsx
let format = (s: string) => s->String.trim

サポートされるアノテーションには @react.component、@genType、@module、@val、@send、@get、@set、@new、@deriving(json)、@deriving(accessors)、@unboxed、@scope、@string、@int、@unwrap、@return、@obj、@variadic、@as、@live、@dead、@inline が含まれます。

Settings > Editor > Inlay Hints > ReScript > PPX annotations で設定します。

インレイヒントはソースコードを煩雑にすることなく型システムを可視化します — 推論された型が各バインディングの横に控えめなアノテーションとして表示され、型推論の簡潔さと明示的な型の利点を両立できます。

rescript.json の JSON Schema¶

Native

プラグインは rescript.json および bsconfig.json 設定ファイルに対して JSON Schema バリデーションと自動補完を提供します。スキーマは ReScript ビルド設定の完全な仕様をカバーしています。

自動補完されるフィールド¶

rescript.json を編集する際、以下を含むすべてのトップレベルおよびネストされたフィールドに対して自動補完とバリデーションが利用できます:

フィールド	説明
`name`	パッケージ名（必須）
`sources`	ソースディレクトリの設定（必須）
`bs-dependencies`	ReScript パッケージの依存関係
`dev-dependencies`	開発時のみの ReScript 依存関係
`jsx`	JSX 変換設定（`version`、`module`、`preserve`）
`suffix`	出力ファイルのサフィックス（例: `.res.mjs`、`.js`）
`package-specs`	モジュール形式（`esmodule` または `commonjs`）
`namespace`	パッケージの名前空間設定
`ppx-flags`	PPX プリプロセッサマクロ
`warnings`	警告番号の設定とエラーへの昇格
`reanalyze`	デッドコード解析設定（`analysis`、`suppress`、`transitive`）
`editor`	エディタ固有の設定（自動補完拡張）
`experimental-features`	実験的なコンパイラ機能（例: `LetUnwrap`）

機能¶

自動補完 --- Ctrl+Space を押すと、任意のネストレベルで利用可能な設定キーを確認できます
バリデーション --- 無効な値はエラーマーカーでハイライトされます（例: サポートされていないモジュール形式の使用）
ホバードキュメント --- 任意のキーにホバーすると、説明と期待される型を確認できます
ネスト構造のサポート --- sources、jsx、reanalyze などのネストされたオブジェクト内での完全な補完

スキーマファイルはプラグインにバンドルされており、rescript.json または bsconfig.json という名前のファイルを開くと自動的に適用されます。

JSON Schema サポートにより rescript.json の編集が推測から案内付きの体験に変わります — 自動補完が有効な設定キーを提案し、バリデーションがコンパイラを実行する前にミスをキャッチします。

Markdown コードフェンスのハイライト¶

Native

Markdown ファイル内の ReScript コードブロックに完全なシンタックスハイライトが適用されます:

```rescript
type user = {name: string, age: int}

let greet = (user) => `Hello, ${user.name}!`
```

統合メカニズム¶

プラグインは 3 つの info-string 識別子を認識する CodeFenceLanguageProvider を登録します:

```rescript --- 主要な識別子
```res --- ReScript 実装ファイルの短縮形
```resi --- ReScript インターフェースファイルの短縮形

Markdown プラグインがこれらの識別子のいずれかを持つコードフェンスを検出すると、シンタックスハイライトを ReScript レクサーに委譲します。これにより、.res ファイルで見られるのと同じトークンレベルのハイライト（キーワード、文字列、コメント、演算子）が提供されます。

要件¶

この機能を使用するには Markdown プラグインがインストールされている必要があります。Markdown プラグインはほとんどの JetBrains IDE にバンドルされています。Markdown プラグインが存在しない場合、コードフェンスはプレーンテキストとして表示されます。

Markdown ファイル内の ReScript コードフェンスは .res ファイルと同じシンタックスハイライトを受け、ドキュメント、README、コード例が視覚的に一貫して読みやすくなります。

JavaScript Injection in %raw()¶

Native

%raw() および %%raw() ブロック内の JavaScript コードに完全な JavaScript シンタックスハイライトが適用され、ReScript ファイル内での快適な FFI（Foreign Function Interface）編集が可能になります。

let add = %raw(`
  function(a, b) {
    return a + b;
  }
`)

let timestamp = %raw(`Date.now()`)

%%raw(`
  import * as fs from 'fs';
  const data = fs.readFileSync('config.json', 'utf8');
`)

言語インジェクションメカニズム¶

プラグインは IntelliJ の MultiHostInjector API を使用して、%raw() ブロック内の文字列リテラルに JavaScript をインジェクトします:

パターン検出 --- インジェクターは、文字列リテラルの前にトークンパターン % raw (（トークン間のオプションの空白あり）が存在するかどうかをチェックします
範囲計算 --- 通常の文字列（"..."）の場合、囲んでいる引用符はインジェクション範囲から除外されます。テンプレート文字列（` ... `）の場合、文字列の全内容が使用されます
言語解決 --- インジェクターは IDE 内で "JavaScript" または "ECMAScript 6" の言語サポートを検索します

利用できる機能¶

インジェクトされた %raw() ブロック内では、以下の機能を利用できます:

JavaScript シンタックスハイライト（キーワード、文字列、数値、コメント）
JavaScript 構文エラーの基本的なエラーハイライト
JavaScript ブロック内の括弧マッチング

要件¶

この機能を使用するには、JetBrains IDE で JavaScript プラグイン（または JavaScript および TypeScript サポート）が利用可能である必要があります。IntelliJ IDEA Ultimate と WebStorm にはデフォルトで含まれています。IntelliJ IDEA Community の場合、JavaScript プラグインを別途インストールする必要がある場合があります。

%raw() 内の JavaScript インジェクションにより、FFI コードを書く際に色なしのプレーン文字列で作業するのではなく、適切な JS シンタックスハイライトとエラー検出が得られます。

RegExp Injection in %re()¶

Native

%re() ブロック内の正規表現に、シンタックスハイライト、バリデーション、括弧マッチングを含む完全な RegExp 言語サポートが提供されます。

let emailPattern = %re("/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/")

let phonePattern = %re("/^\+?[1-9]\d{1,14}$/")

let urlPattern = %re("/^https?:\/\/[\w\-]+(\.[\w\-]+)+[/#?]?.*$/i")

言語インジェクションメカニズム¶

プラグインは IntelliJ の MultiHostInjector API を使用して、%re() ブロック内の文字列リテラルに RegExp 言語をインジェクトします:

パターン検出 --- インジェクターは、文字列リテラルの前にトークンパターン % re ( が存在するかどうかをチェックします
範囲計算 --- 正規表現の区切り文字（/ ... /）が検出され、インジェクション範囲は区切り文字間の内容に設定されます
フラグ処理 --- 閉じ区切り文字の後の正規表現フラグ（例: i、g、m）は RegExp 言語に渡されます

利用できる機能¶

インジェクトされた %re() ブロック内では:

RegExp シンタックスハイライト（文字クラス、量指定子、グループ、アンカー）
無効な正規表現パターンのエラーハイライト
グループ ( ... ) の括弧マッチング
正規表現構文のホバードキュメント（RegExp プラグインが提供する場合）

要件¶

この機能は IntelliJ の組み込み RegExp 言語サポートを使用しており、すべての JetBrains IDE で利用できます。

RegExp インジェクションにより %re() パターン内でシンタックスハイライトとバリデーションが得られ、正規表現エラーをランタイムではなく編集時にキャッチできます。

インジェクトされた言語のフォーマット¶

Native

ReScript ファイルをフォーマット（Cmd+Option+L）すると、インジェクトされた言語フラグメント（例: %raw() 内の JavaScript）もそれぞれの言語のフォーマットルールに従ってフォーマットされます。

この機能はインジェクトされた言語のフォーマッタにフォーマットを委譲する FormattingModelBuilder を提供し、インジェクトされたコードが ReScript コードと一緒に適切にフォーマットされた状態を維持します。

ReScript ファイルをフォーマットすると、%raw() 内のインジェクトされた JavaScript もそれ自身のルールに従ってフォーマットされるため、単一のフォーマットコマンドで両方の言語がクリーンに保たれます。

Grazie 統合¶

Native

Grazie プラグインがインストールされている場合、ReScript プラグインはコメントと文字列リテラルから自然言語テキストを抽出し、文法・スペルチェックを行います。

サポートされるテキストドメイン:

コメント — 行コメント（//）、ブロックコメント（/* */）、ドキュメントコメント（/** */）が COMMENTS ドメインテキストとして抽出されます
文字列 — 文字列リテラル、テンプレート文字列、文字リテラルが LITERALS ドメインテキストとして抽出されます

これはオプションの統合です --- Grazie がインストールされていない場合、この機能は単に利用できません。

Grazie 統合により、ReScript のコメントと文字列が自然言語テキストと同じ文法・スペルチェックを受け、ツールを切り替えることなくドキュメントの品質を向上できます。

Index Pattern Builder¶

Native

ReScript ファイル用のレクサーベースのインデックスパターンビルダーを提供し、IDE の TODO/FIXME 検出を強化します。基本的なテキストベースのアプローチと比較して、コメント内のより正確なパターンマッチングを実現します。

インデックスパターンビルダーは ReScript JFlex レクサーを使用してコメントトークン（行コメント、ブロックコメント、ドキュメントコメント）を正しく分類し、TODO/FIXME パターンが文字列リテラルやコードではなく実際のコメント内でのみマッチすることを保証します。

レクサー対応の TODO 検出により偽陽性を防ぎます — 「TODO」という単語を含む文字列リテラルではなく、実際のコメント内の TODO のみがインデックスされます。

Element Signature Provider¶

Native

IDE の再起動をまたいでエディタの折りたたみ状態を永続化する安定した要素シグネチャを提供します。エディタでコードブロックを折りたたむと、ファイルの変更後も維持されるシグネチャ形式（TYPE#name#offset）を使用してその折りたたみ状態が記憶されます。

これによりコード折りたたみの設定が IDE セッション間で永続化されます — 折りたたんだブロックは編集や再起動後もそのまま維持されます。

プロジェクトウィザード¶

Native

フロントエンド、バックエンド、サーバーレス、モバイルなどをカバーする 16 の事前設定済みテンプレートを使用して、IDE から直接新しい ReScript プロジェクトを作成します。

手順¶

File > New > Project
左側のジェネレーターリストから ReScript を選択します
プロジェクト設定を構成します:
- プロジェクト名 と 保存場所
- テンプレート --- カテゴリ別にグループ化された 16 のプロジェクトテンプレートから選択します
- パッケージマネージャ --- npm、pnpm、yarn、または bun から選択します
- バリデーションライブラリ --- zod と sury から選択します。全テンプレートがこの選択を Validation.res に反映し、テンプレートごとに異なる入力（HTTP ボディ、CLI オプション、フォーム入力、IPC ペイロード、設定ファイル、public API 引数）を検証します。
Create をクリックしてプロジェクトを生成します

利用可能なテンプレート¶

カテゴリ	テンプレート	説明
Basic	Basic	コンソール出力付きの最小限の ReScript プロジェクト
Frontend	Vite + React	Vite バンドラーを使用した React シングルページアプリケーション
Frontend	Next.js	Next.js を使用したサーバーサイドレンダリング React アプリケーション
Desktop	Electron	Electron を使用したクロスプラットフォームデスクトップアプリケーション
Backend	Hono (Node.js)	Node.js 上の Hono フレームワークによる軽量 Web サーバー
Backend	Hono GraphQL	`graphql-yoga` を `/graphql` にマウントした Hono サーバー。GraphiQL UI と Drizzle による永続化を備える
Serverless	Cloudflare Workers	Hono を使用した Cloudflare Workers 上のサーバーレス API
Serverless	AWS Lambda	Hono を使用した AWS Lambda 上のサーバーレス関数
Serverless	Google Cloud Run	Hono を使用した Google Cloud Run 上のコンテナベースサービス
Mobile	React Native (Expo)	React Native と Expo を使用したモバイルアプリケーション
Mobile	React Native (Community CLI)	React Native Community CLI（bare workflow）を使用したモバイルアプリ。ネイティブの Android/iOS プロジェクトに直接アクセス可能。
Library	npm Library	TypeScript 利用者向けの `@genType` 付き公開可能な npm パッケージ
Tool	CLI Tool	引数解析付きのコマンドラインツール
Full Stack	Monorepo (Hono + React)	Hono バックエンドと React フロントエンドのフルスタック Monorepo
Full Stack	Full-Stack (single package)	Monorepo の単一パッケージ版: 1 つの `package.json` で Hono バックエンドと Vite+React クライアントを同居させる
Full Stack	res-x (Bun 上の HTMX)	`rescript-x` の JSX と HTMX で構築するサーバ駆動型 Web アプリ。Bun + Vite 上で動作する

テンプレートごとの詳細ページ (生成レイアウト、依存関係、主要ファイル、スクリプト、2 日目以降のレシピ) については、プロジェクトテンプレートを参照してください。

生成されるプロジェクト構造¶

各テンプレートは rescript.json、package.json、およびテンプレート固有のソースファイルを含む、すぐに使えるプロジェクトを生成します。

Basic テンプレート:

my-project/
+-- rescript.json
+-- package.json
+-- src/
    +-- App.res

Vite + React テンプレート:

my-project/
+-- rescript.json
+-- package.json
+-- index.html
+-- vite.config.mjs
+-- src/
    +-- App.res
    +-- Main.res

Monorepo テンプレート:

my-project/
+-- package.json            # Root with workspaces
+-- packages/
    +-- shared/
    |   +-- rescript.json
    |   +-- package.json
    |   +-- src/Types.res
    +-- server/
    |   +-- rescript.json
    |   +-- package.json
    |   +-- src/Server.res
    +-- client/
        +-- rescript.json
        +-- package.json
        +-- src/App.res

テンプレートの詳細¶

React ベースのテンプレート（Vite+React、Next.js、Electron、React Native (Expo)、React Native (Community CLI)）は rescript.json の JSX 設定と React 依存関係を含みます。

React Native (Community CLI) は、ネイティブの android/ と ios/ プロジェクトに直接アクセスしたい Android Studio / Xcode ユーザーを対象としています。このテンプレートには JavaScript/TypeScript + ReScript の部分と .res.mjs を解決する metro.config.js のみが含まれており、ネイティブプロジェクト自体はプロジェクト作成後に @react-native-community/cli を実行して生成します。src/NativeGreeting.res は、@module("react-native") @scope("NativeModules") 経由でカスタム Kotlin/Swift NativeModule をバインドする方法を示していますが、Kotlin/Swift の実装自体はテンプレートの範囲外であり、公式 React Native ドキュメントに従って記述する必要があります。

Hono ベースのテンプレート（Hono、Hono GraphQL、Cloudflare Workers、AWS Lambda、Google Cloud Run）は共通の Hono バインディング（src/Hono.res）を共有し、デプロイ設定が異なります:

Hono (Node.js) --- ローカル開発に @hono/node-server を使用
Cloudflare Workers --- wrangler.jsonc 設定を含む
AWS Lambda --- esbuild バンドルと Lambda アダプターバインディングを含む
Google Cloud Run --- コンテナ化デプロイ用の Dockerfile を含む

npm Library は TypeScript 型定義を生成するための @genType 設定を含みます。

CLI Tool は package.json の bin エントリと Process.argv による引数解析を含みます。

バリデーションライブラリ¶

全 16 テンプレートに Validation.res モジュールが同梱されており、バックエンドは バリデーションライブラリ ウィザードオプションで zod（デフォルト）または sury（ReScript ネイティブ）から選択できます。関数シグネチャはバックエンドに関わらず parseXxx: <input> => result<T, string> で共通のため、呼び出し側がライブラリ選択で分岐する必要はありません。各テンプレートが検証するのはそれぞれの入力境界の形に対応します:

テンプレート	検証対象
Hono / Hono GraphQL / AWS Lambda / Cloudflare Workers / Google Cloud Run / Next.js / Full-Stack / Monorepo / res-x	受信する HTTP JSON ボディ（失敗時は HTTP 400 を即返す）
CLI Tool	`init --name / --dir` サブコマンドのオプション
npm Library	JS/TS 呼び出し元からの public API 引数
Basic	`--config` 指定時の `config.json` の shape
Electron	main プロセスから返される IPC レスポンス
React Native (Expo) / React Native (Community CLI)	フォームの draft todo 入力
Vite + React	fetch 呼び出し前の greet フォーム入力

プロジェクト作成後¶

ウィザードがプロジェクトを作成した後:

パッケージマネージャの install コマンド（例: pnpm install）を実行して依存関係をインストールします
rescript build を実行（または ReScript 実行構成を使用）してプロジェクトをコンパイルします
node_modules に @rescript/language-server が利用可能になると、Language Server が自動的に起動します

開発者体験の向上¶

生成される各プロジェクトには共通のベースラインが同梱されており、すぐにコーディングを開始できます:

README.md — 前提条件、選択したパッケージマネージャ向けに調整されたインストール/開発コマンド、テンプレート固有のデプロイ手順 (例: Cloudflare Workers の wrangler deploy、AWS Lambda アップロード、Cloud Run の gcloud run deploy) を記載
.gitignore — node_modules/、ReScript ビルド成果物、OS ファイル、テンプレート固有の出力 (.next/、dist/、.wrangler/ など) を除外
.editorconfig — インデント (スペース 2) と改行コード (LF) を固定
.github/workflows/ci.yml — 依存関係をインストールして rescript を実行する最小限の CI パイプライン。テンプレートが定義している場合は build / test スクリプトも実行
package.json の packageManager フィールド — Corepack 向けにツールチェインのバージョンを固定し、コラボレーターが同じパッケージマネージャを使えるようにする
Vitest スモークテスト + カバレッジ — すべてのテンプレートに src/__tests__/*.test.mjs (またはワークスペース相当) と test / test:coverage スクリプト (@vitest/coverage-v8 提供) が同梱されています。Monorepo は pnpm -r run test / yarn workspaces foreach / npm --workspaces run test --if-present でワークスペース横断に実行し、React Native は Node では react-native を読み込めないためファイルシステムスモークテストを、Hono 系テンプレは Hono 内蔵の app.request() ハーネスで DB フリーのベースラインルートを検証します
.nvmrc / LICENSE / .github/dependabot.yml — すべてのテンプレートが Node メジャーバージョンを固定し、プロジェクト名を著作権者とする MIT ライセンスを同梱、Dependabot を npm + GitHub Actions の依存を週次でポーリングするよう設定しています
.env.example — 環境変数を読むテンプレート (Hono REST、Hono GraphQL、Full-Stack、Monorepo サーバー、Google Cloud Run) は期待されるキー (DATABASE_URL、PORT 等) を記載した .env.example を同梱します。値を入れた .env は .gitignore で除外されるため誤ってコミットされません
Hono app.onError グローバルハンドラ — Hono 系テンプレート (REST、GraphQL、Full-Stack、Monorepo サーバー) は app.onError で例外をログに出力して JSON 500 を返すよう配線されており、未処理例外がクライアントに生のスタックトレースを漏らすことがありません
依存バージョンの一元管理 — すべてのテンプレートのバージョンは wizard/templates/TemplateVersions.kt に集約されており、夜間の GitHub Actions ジョブ (integration-tests.yml) が各テンプレートが引き続きインストール・コンパイル可能であることを検証します

Vite+ ツールチェイン (Vite + React、Electron、Monorepo)¶

Vite + React、Electron、Monorepo の各テンプレートは Vite+ (vite-plus) を使用しています — Vite、Vitest、Oxlint、Oxfmt、Rolldown をまとめた統合ラッパーです。スクリプトは vp dev、vp build、vp test などで公開されます。

補足: Vite+ は vite パッケージが自身のコアビルドに解決されることを要求するため、これらのテンプレートは vite を @voidzero-dev/vite-plus-core の npm エイリアスとして宣言しています。アップグレード時もこのエイリアスを維持してください（ずれた場合は vp migrate で揃えられます）。クラシックな Vite に戻すには、vite を通常のパッケージに戻し、vite.config.mjs の vite-plus を vite に置き換え、npm スクリプトを vite / vite build に切り替えます。

プロジェクトウィザードにより数秒で完全に設定された ReScript プロジェクトを作成できます — テンプレートを選択し、パッケージマネージャを選び、設定ファイルを手動で書くことなくビルド可能なプロジェクトを取得できます。

ファイルテンプレート¶

Native

コンテキストメニューから、事前に記入されたボイラープレートコード付きの新しい ReScript ファイルを作成します。

使い方¶

Project パネルでディレクトリを右クリックします
New > ReScript File を選択します
ファイル名（拡張子なし）を入力します
ドロップダウンからテンプレートを選択します

利用可能なテンプレート¶

Module --- モジュールコメントヘッダー付きの .res ファイルを作成します:

// MyModule module

Interface --- コメントヘッダー付きの .resi インターフェースファイルを作成します:

// MyModule interface

Component --- React コンポーネントのボイラープレート付きの .res ファイルを作成します:

@react.component
let make = () => {
  <div> {React.string("MyComponent")} </div>
}

すべてのテンプレートにおいて、入力したファイル名が自動的にテンプレートの内容に置換されます。Component テンプレートは React プロジェクトで特に便利で、すぐに使える JSX 付きの関数コンポーネントが提供されます。

テンプレートのカスタマイズ¶

ファイルテンプレートは Settings > Editor > File and Code Templates でカスタマイズできます。Internal タブで "ReScript" で始まる名前のテンプレートを探してください。IntelliJ のテンプレート変数構文（例: ${NAME} でファイル名）を使用してテンプレートの内容を変更できます。

ファイルテンプレートにより新しいモジュール、インターフェース、React コンポーネントの一貫した出発点が得られ、既存ファイルからボイラープレートをコピーすることなくすべての新規ファイルが同じパターンに従います。

.d.ts バインディング生成¶

バインディング生成にはコマンド全体で30秒のタイムアウトがあり、IDEの進捗取消に対応し、各出力ストリームを4 MiBに制限します。REPLのコンパイルとNode.js実行にはそれぞれ独立した30秒の制限と同じ出力上限を適用します。タイムアウト、取消、出力超過時には所有プロセスと観測済みの子プロセスを停止し、失敗理由を通知します。観測前に切り離された子プロセスの停止は、プロセス検出では保証できません。

Native

TypeScript .d.ts 定義ファイルから ReScript external バインディングコードを生成します。FFI 宣言を手動で記述する煩雑な作業を自動化します。

使い方¶

Project パネルで .d.ts ファイルを右クリックします
Generate ReScript Binding を選択します
プラグインが TypeScript Compiler API を使用してファイルを解析し、バインディング宣言を含む .res ファイルを生成します

このアクションは .d.ts ファイルを開いているときのエディタコンテキストメニューからも利用できます。

サポートされる構文¶

TypeScript	ReScript 出力
`function`	`@module external fn: params => ret = "fn"`
`interface`	レコード型 `type t = { field1: string, field2?: int }`
`class`	`@new`、`@get`、`@send` external 付きモジュール
`type` エイリアス	`type t = typeStr`
`enum`（文字列）	ポリモーフィックバリアント `type t = [#"a" \| #"b"]`
`enum`（数値）	`@inline let` 定数付きモジュール
`const` / `let`	`@module external name: type = "name"`

型マッピング¶

TypeScript	ReScript
`string`	`string`
`number`	`float`
`boolean`	`bool`
`void`	`unit`
`any` / `unknown`	`JSON.t`
`T \| null`	`Nullable.t<T>`
`T \| undefined`	`option<T>`
`Array<T>` / `T[]`	`array<T>`
`Promise<T>`	`promise<T>`
`Record<string, T>`	`Dict.t<T>`
`[A, B, C]`	`(A, B, C)`
`(a: A) => B`	`A => B`
文字列リテラルユニオン	`@string` 付きポリモーフィックバリアント

要件¶

Node.js が PATH に存在するか、Settings で設定されている必要があります
TypeScript がプロジェクトの node_modules にインストールされている必要があります（プラグインは Monorepo サポートのため親ディレクトリも検索します）

制限事項¶

以下の TypeScript 構文はまだサポートされておらず、/* TODO */ コメントが生成されます:

条件型とマップ型
テンプレートリテラル型
制約付きの複雑なジェネリクス
交差型（JSON.t にフォールバック）
オーバーロードされた関数シグネチャ（最初のシグネチャを使用）
宣言マージ

TypeScript ライブラリの ReScript FFI バインディングを書くことは ReScript 開発で最も面倒なタスクの一つです — このジェネレータは変換を自動化し、ゼロから書くのではなく洗練できる正しい external 宣言を生成します。

カラープレビュー¶

Native

ReScript コード内のカラー値に対して、エディタガターにインラインカラースウォッチが表示されます:

16 進数カラー: "#ff0000"、"#f00"
RGB: "rgb(255, 0, 0)"
HSL: "hsl(0, 100%, 50%)"

スウォッチをクリックするとカラーピッカーが開きます。

let primaryColor = "#3498db"
let errorColor = "rgb(231, 76, 60)"
let successColor = "hsl(120, 39%, 49%)"

文字列リテラル内のカラー値が検出され、対応する行の横のエディタガターに小さなカラースウォッチが表示されます。

インラインカラースウォッチによりアプリケーションを実行せずに色の値を視覚的に確認でき、hex、RGB、HSL コードの横に実際の色が表示され、クリックしてカラーピッカーで調整できます。

VCS Code Vision¶

Native

トップレベル宣言（let、type、module、external）に作成者と最終変更の注釈が表示され、エディタ内で直接 Git blame 情報を確認できます。Settings > Editor > Inlay Hints > Code Vision で有効化します。

宣言上の VCS アノテーションにより各関数や型を最後に変更した人が表示され、git blame を別途実行せずに不慣れなコードについて誰に尋ねればよいかが分かります。

パッケージ依存関係¶

Native

rescript.json の dependencies と devDependencies を表示する専用ツールウィンドウです:

開き方: View > Tool Windows > ReScript Dependencies

ツリービューはパッケージを "Dependencies" と "Dev Dependencies" のグループにバージョン番号付きで整理します。

パッケージ依存関係ビューにより rescript.json を開いたり npm list を実行したりせずに、プロジェクトの ReScript 依存関係とバージョンの概要を素早く確認できます。

Quick Documentation¶

LSP Required

Ctrl+Q（またはホバー）を押して ReScript 要素のドキュメントを表示します。LSP サーバーが接続されている場合、ドキュメントは Language Server から提供されます。LSP が利用できない場合は、PSI ベースのフォールバックが宣言の型、名前、ソースファイルを表示します。

Quick Documentation は現在の位置から離れることなく型情報とドキュメントコメントを表示し、コーディング中にインラインで API を理解できます。

Safe Delete¶

Native

Refactor > Safe Delete を使用して、使用箇所チェック付きで ReScript 宣言を削除します。要素がまだ参照されている場合、続行前にすべての使用箇所を示す確認ダイアログが表示されます。

Safe Delete は宣言を削除する前に参照をチェックして偶発的な破損を防ぎ、隠れた依存関係を心配することなく自信を持ってコードをクリーンアップできます。

名前候補の提案¶

Native

リネームリファクタリング時に、プラグインは以下に基づいて名前を提案します:

要素の型（例: User.t に対して user）
含まれるファイル名
snake_case から camelCase への変換

インテリジェントな名前提案によりコンテキストに適切な名前を提案してリネームリファクタリングを高速化し、ゼロから考え出すのではなくリストから良い名前を選べます。

Reader Mode¶

Native

node_modules/ ディレクトリ内のファイルは自動的に Reader Mode で表示され、ライブラリソースファイルのクリーンな読み取り専用ビューを提供します。

Reader Mode はライブラリのソースファイルをクリーンで気が散らない表示にし、依存関係の動作を探索する際にサードパーティコードを読みやすくします。

TODO インデキシング¶

Native

プラグインは IntelliJ の TODO ツールウィンドウ（Alt+6 > TODO タブ）と統合し、ReScript ファイル内の TODO、FIXME、およびその他のタスクコメントを検出してリスト表示します。

認識されるパターン:

// TODO: ...
// FIXME: ...
/* TODO: ... */

TODO 項目は IDE の TODO パネルに、プロジェクト内の他のファイルタイプの項目と共に表示されます。TODO パターンとフィルタは Settings > Editor > TODO でカスタマイズできます。

TODO インデキシングにより ReScript のタスクコメントが IDE の統合 TODO パネルに取り込まれ、すべての言語にわたる未完了の作業を一箇所で追跡できます。

Open ステートメントインデックス¶

Native

プラグインはプロジェクト全体のすべての open ステートメントをインデックス化し、高速なモジュール解決を実現します。自動インポート候補やモジュール依存関係分析などの機能を支えています。

open 文インデックスによりプロジェクト全体で即座にモジュール検索が可能になり、リクエストごとにファイルをスキャンすることなく自動インポートと依存関係分析を実現します。

Project View の拡張¶

Native

インターフェース表示: 対応する .resi を持つ .res ファイルにはインターフェースインジケーター: 対応する .resi を持つ .res ファイルに "(has .resi)" サフィックスを表示
バージョン表示: rescript.json にその内容から ReScript バージョンを表示
コンパイル済み JS のネスト: コンパイル済み JS ファイル（.res.js/.mjs/.cjs、.bs.js/.mjs/.cjs）が Project パネルで対応する .res ソースファイルの下にネスト表示され、視覚的な混乱を軽減します
コンパイル済み JS のグレー表示: ネストされたコンパイル済み JS ファイルはグレーのテキストで表示され、生成された出力とソースファイルを視覚的に区別します

Project View の拡張により、生成されたファイルをソースの下にネストし、インターフェースの有無や ReScript バージョンなどの有用なメタデータを表示して視覚的な混乱を減らし、ファイルツリーがソースコードに集中できます。

自動インポートオプション¶

Native

Settings > Editor > General > Auto Import で自動インポートの動作を設定します:

open ステートメントの自動挿入の切り替え
特定のモジュールを自動インポートから除外

きめ細かな自動インポート設定により、どのモジュールが自動的に open されるかを制御でき、不要なインポートがファイルを散らかすのを防ぎます。

式の型表示¶

LSP Required

Ctrl+Shift+P（macOS では Cmd+Shift+P）を押すと、カーソル位置の式の推論された型を表示します。

let add = (a, b) => a + b
// Place caret on "add", press Ctrl+Shift+P
// Shows: (int, int) => int

型情報は LSP の textDocument/hover リクエストを介して Language Server から取得されます。LSP が接続されていない場合、型情報が利用できない旨のメッセージが表示されます。

Tip

明示的な型注釈を追加せずにサブ式の型を素早く確認したい場合に便利です。Inlay Hints（型を常時表示する）とは異なり、Expression Type はオンデマンドで動作し、宣言だけでなく任意の式に対して使用できます。

Expression Type は任意の式に対するオンデマンドの型検査を提供します — 永続的なインレイヒントと異なり、必要な時だけ呼び出すことでエディタをクリーンに保ちつつ型情報に即座にアクセスできます。

Type Info ツールウィンドウ¶

LSP Required

現在のキャレット位置の式の推論された型を常時表示する永続的なツールウィンドウです。オンデマンドで型を表示する Expression Type（Ctrl+Shift+P）とは異なり、Type Info ツールウィンドウはコードをナビゲートするたびに自動更新されます。

開き方: View > Tool Windows > ReScript Type

仕組み¶

ReScript ファイル内でキャレットを移動すると、ツールウィンドウは現在の位置に対して LSP textDocument/hover リクエストを送信します
レスポンスはデバウンスされ、高速なナビゲーション中の過剰なリクエストを回避します
推論された型がツールウィンドウパネルに表示され、リアルタイムで更新されます

シンタックスハイライト¶

型シグネチャは EditorTextField + ReScript file type 経由で描画されるため、.res エディタ内と同じカラースキームでキーワード・型構築子・演算子・型変数が色付けされる。IDE のカラースキームを切り替えるとパネルも自動で追従するため、別途テーマ設定は不要。

ユースケース¶

不慣れなコードの探索 --- ショートカットを押さずに型を継続的に確認できます
型エラーのデバッグ --- 式を移動して型がどこで分岐するかを理解できます
ReScript の学習 --- 型システムがさまざまな式に対してどのように型を推論するかを観察できます

要件¶

Type Info ツールウィンドウを使用するには Language Server が実行されている必要があります。LSP が接続されていない場合、パネルに "No type information available" メッセージが表示されます。

Type Info ツールウィンドウはコードをナビゲートする際に常時型を可視化します — ショートカットが必要な Expression Type と異なり、このパネルは自動更新されるため、不慣れなコードベースの探索に最適です。

LSP 自動インストール¶

Native

@rescript/language-server がインストールされていない ReScript プロジェクトを開くと、プラグインがワンクリックインストールボタン付きの通知を表示します。

通知アクション¶

アクション	説明
npm/yarn/pnpm でインストール	検出されたパッケージマネージャを使用して `@rescript/language-server` を devDependency としてインストールします
Configure...	カスタム LSP パスを設定するための ReScript 設定ページを開きます
Don't show again	現在のセッションで通知を非表示にします

インストールはプログレスインジケーター付きでバックグラウンドで実行されます。成功すると Language Server が自動的に起動し、IDE の再起動は不要です。

通知は以下の条件をすべて満たす場合にのみ表示されます:

プロジェクトに rescript.json または bsconfig.json が含まれている
Settings にカスタム LSP パスが設定されていない
node_modules に Language Server が見つからない

LSP 自動インストールは最も一般的なセットアップの障壁を取り除きます — npm コマンドを手動で実行してパスを設定する代わりに、ワンクリックで Language Server をインストールして自動的に起動します。

GitHub エラーレポーター¶

Native

プラグインには未処理の例外を GitHub Issues に送信する自動エラーレポートシステムが含まれており、メンテナーがバグを素早く特定して修正するのに役立ちます。

仕組み¶

プラグイン内で予期しない例外が発生すると、IDE の標準エラーダイアログに Report to Plugin Author ボタンが表示されます。このボタンをクリックすると、ブラウザで以下の情報が事前入力された GitHub issue が開きます:

例外のスタックトレース
プラグインバージョンと IDE バージョン
オペレーティングシステム情報

プライバシー¶

エラーレポートはブラウザで GitHub issue のドラフトとして開きます。送信前に内容を確認・編集できます。データは自動的には送信されません --- 共有する内容を完全にコントロールできます。

要件¶

エラーレポートの送信には GitHub アカウントが必要です。レポートはプラグインの GitHub リポジトリの issue トラッカーに開きます。

エラーレポーターによりプラグインの改善への貢献が容易になります — 問題が発生した時、事前入力された GitHub issue により最小限の労力で問題を報告でき、共有内容を完全にコントロールできます。

インスペクション抑制¶

Native

// noinspection コメントを使用して特定のインスペクションを抑制します:

// noinspection RescriptDuplicateOpen
open Belt
open Belt  // This duplicate open won't be flagged

特定の箇所でインスペクションが偽陽性を出す場合、グローバルに無効にするのではなくコメントで抑制でき、他の場所ではインスペクションを有効に保てます。

フレームワーク検出¶

Native

プラグインは rescript.json ファイルを探すことで ReScript プロジェクトを自動的に検出します。rescript.json を含むプロジェクトを開くと、IDE はそれを ReScript プロジェクトとして認識し、それに応じたフレームワークの設定を提案します。

これによりプロジェクト固有の設定やツール統合などのフレームワーク対応機能が有効になります。

自動フレームワーク検出により、ReScript プロジェクトを開くとすぐにプラグインの全機能セットが有効になり、手動設定は不要です。

コード並べ替え¶

Native

Code > Rearrange Code により、ReScript ファイルのトップレベル宣言を標準的な順序に並べ替えます。

デフォルトの順序は以下のとおりです:

open / include ステートメント
type 宣言
exception 宣言
module 宣言
external 宣言
let 宣言

これによりプロジェクト全体で一貫したファイル構造を維持できます。

自動並べ替えによりすべてのファイルで一貫した宣言順序が強制され、個々の開発者の習慣に頼ることなく型、モジュール、関数がどこにあるかを常に把握できます。

モジュール依存関係ダイアグラム¶

Native

モジュールの依存関係を IDE 内でトップダウンの階層グラフとして描画したり、外部レンダラに貼り付けるための Mermaid / Graphviz DOT ソーステキストとして取得したりできます。

開き方: View > Tool Windows > ReScript Module Diagram、または Tools > Show ReScript Module Diagram を使用します

仕組み¶

ダイアグラムプロバイダはプロジェクト内のすべての .res ファイルをスキャンし、open と include 文から有向グラフを構築します。各モジュールがノードになり、open ModuleName や include ModuleName ごとに現在のモジュールから参照先への辺が追加されます。結果は両方の描画モードに同時に渡されるため、トグルを切り替えてもグラフは再構築されません。

Visual モードと Source モード¶

ツールバーの Visual / Source トグルで、同じグラフを 2 つの描画モードで切り替えられます:

Visual モード（デフォルト） — Java2D で描画されるトップダウンの階層ダイアグラム。レイヤー割当は Kahn の BFS で行い、入ってくる辺が無いモジュール（典型的には Main のようなエントリポイント）が一番上のレイヤーに置かれ、下流の依存は 1 つ下のレイヤーに押し下げられます。サイクルに含まれるモジュールは Kahn の BFS では順序付けできないため、その他のレイヤーの下に追加された 1 レイヤーにまとめて配置され、常に可視のまま残ります。辺は依存元モジュールの下辺から依存先モジュールの上辺へのオーソゴナル矢印として描画され、自己ループは描画されません。
Source モード — Mermaid flowchart TD ソースを表示する読み取り専用の JEditorPane。MermaidSourceColorizer がトークンを色分けする (flowchart / graph / TD / LR / subgraph / end はキーワード色、--> / --- / -.-> / ==> は演算子色、"…" ノードラベルは文字列色、%% コメントはコメント色)。これにより、ソースビューは単色プレーンテキストではなくコードとして読める。Copy-as-Mermaid は引き続き raw text をエクスポートする。

ノードの色分け¶

Visual モードは依存関係グラフ上の位置に基づき各モジュールを 4 種類の structural role に分類し、role 別の色で box を描画する。canvas 下部の凡例ストリップで対応を示す。

ロール	定義	意味
エントリポイント	in-degree 0 でサイクル外	他のどのモジュールからも依存されないモジュール — 通常は `Main`、アプリのエントリ、トップレベルのバイナリ
中間	in-degree と out-degree がともに正	中継モジュール: 他に依存し、他から依存される
葉ノード	out-degree 0 でサイクル外	純粋なシンク: プロジェクト内の他モジュールを open / include しない (多くは基本ユーティリティ)
サイクル	Kahn の BFS でドレインできない	強連結成分のメンバー — ほどく必要のある循環依存

サイクル内のメンバーは fallback layer 上にあっても目立つよう専用色で塗られる。パレットは JBColor(light, dark) ペアで構成されており、Light/Dark の両 IDE テーマで読みやすい contrast を確保する。

ツールウィンドウのレイアウト¶

ツールバー: Visual / Source トグル、Refresh（現在の PSI からグラフを再構築）、Copy as DOT、Copy as Mermaid
メイン領域: Visual グラフまたは Mermaid ソースを、CardLayout でその場で切り替えます
ステータスバー: モジュール数と辺の数

エクスポート¶

どちらのモードでも、両方のツールバーコピーアクションをそのまま利用できます:

Copy as Mermaid — flowchart TD テキストをクリップボードにコピーします。Mermaid Live Editor や Mermaid 対応の Markdown ファイルに貼り付けるとグラフがレンダリングされます
Copy as DOT — Graphviz の digraph をクリップボードにコピーします。dot -Tpng にパイプしたり、.dot ファイルに貼り付けて Graphviz でレンダリングできます

空白・ピリオド・引用符を含むモジュール名は自動的にエスケープされるため、エクスポート結果はいずれのレンダラにもそのまま渡せます。

ユースケース¶

プロジェクト構造の理解 — IDE を離れることなく、モジュール間の関係を一目で確認できます
密結合の特定 — Visual モードで依存関係が多すぎるモジュールを発見できます
サイクルの発見 — サイクルに含まれるモジュールはフォールバックレイヤーにまとめて配置されるため、循環依存はクリーンな DAG と視覚的に明確に区別できます
リファクタリング計画 — モジュールの移動や分割の影響を把握できます。Source モードに切り替えてコピーすれば、調査結果を PR や設計書で共有できます

依存関係ダイアグラムはプロジェクトのモジュール構造を視覚的に明らかにし、コードだけでは見えにくい循環依存、密結合モジュール、リファクタリングの機会を容易に発見できます。

Variant Flow ダイアグラム¶

Native

カーソル位置の switch 式を decision tree として可視化します。大きなマッチやネストしたマッチでも、ソースをスクロールせずに構造を一目で把握できます。

開き方: View > Tool Windows > ReScript Switch Flow、または Tools > Show Switch Flow Diagram を使用します

仕組み¶

プロバイダは型絞り込みビジュアライザと同じ構文ベースの switch arm コレクタでファイルを走査し、カーソルを含む最も内側の switch（switch キーワード上のカーソルも対象）を選び、Mermaid flowchart TD のノード木を生成します。ルートノードはスクラティニーで、各 arm は子ノードとなります。エッジラベルはパターンサマリー（Some(_)、Ok(_) 等）、ノードラベルは arm body の最初の非空行（最大 40 文字）です。arm body 内のネストした switch は再帰的に展開され、深さ 3 を超えると "(deeper switch hidden)" の単一葉に折り畳まれて図の可読性を保ちます。

カーソル移動から 200ms 後にビューを再描画するため、ファイル内をカーソル移動するだけでプロジェクトの switch 式を自然にスキャンできます。

Visual モードと Source モード¶

ツールウィンドウにはツールバーから切替できる 2 つの表示モードがあります:

Visual (デフォルト) — 自己完結型の Swing グラフビューがスクラティニーと各 arm を角丸ボックスとオーソゴナル矢印で描画する。ジオメトリは純粋な computeLayout ヘルパーで算出されるため、レンダラーは JCEF ブラウザも mermaid.js も外部 Graphviz バイナリも必要としない。
Source — MermaidSourceColorizer によるトークン色付け (キーワード / 矢印 / 引用ノードラベル / %% コメント) を施した Mermaid flowchart TD ソースを表示する読み取り専用の JEditorPane で、ソースビューがコードのように読める。共有前に diagram テキストを確認したいときはこのモードに切り替える。Copy-as-Mermaid は引き続き raw text をエクスポートする。

Visual モードはネストした switch arm を親 arm box の下にサブツリーとして展開する。Mermaid / DOT exporter と同じ MAX_NESTING_DEPTH 制限を踏襲 (それを超える深さは (deeper switch hidden) リーフに折り畳まれる)。フラットな単層マッチではツールウィンドウが狭いと追加行に折り返す arm box の列にフォールバックするため、どんなレイアウトでも diagram は使い物になる。Source モードは Mermaid テキストを行単位のハイライト付きで描画し、後述の 2 つの copy アクションでも生の Mermaid 文字列を真として保持する。

Arm の色分け¶

Visual モードは各 arm を 5 種類の arm kinds に分類し、kind 別の色で box を描画する。canvas 下部の凡例ストリップで対応を示すので、絵が自己説明的になる。

Arm kind	トリガー	出現タイミング
Constructor	パターンが大文字始まりの識別子 (`Some(_)`、`Ok(value)`、`Red` 等)	Variant またはポリモーフィック・バリアントのコンストラクタ arm
Wildcard	パターンがちょうど `_`	何にもマッチして束縛を伴わない catch-all arm
バインディング	パターンが小文字始まりの単一識別子 (例: `	other =>`)
Todo	body テキストが `todo` リテラルから始まる	Add Missing Switch Arms Intention が挿入した未実装 arm、または手書きで残された未実装 arm
Nested	Arm が別の `switch` を含み、サブツリーを描画する	ネストしたパターンマッチ

パレットは JBColor(light, dark) ペアで構成されており、Light/Dark の両 IDE テーマで読みやすい contrast を確保する。色を使って未実装 arm を見つけたり (長い match の中で黄色の Todo 行がすぐ目に入る)、ラベルを読まずにネストした switch の構造を辿ったりできる。

ツールウィンドウのレイアウト¶

ツールバー: Visual / Source トグル、Refresh（ダイアグラムを再構築）、Jump to Switch、Copy Mermaid、Copy DOT
メイン領域: アクティブなトグルに応じて Visual グラフビューもしくは読み取り専用 Mermaid ソースが表示されます
ステータスバー: 現在のダイアグラムに含まれる arm 数、カーソルが switch 内にない場合はプレースホルダー文言

エクスポート¶

Copy Mermaid — flowchart TD テキストをクリップボードにコピーします。Mermaid Live Editor や Mermaid 対応の Markdown ファイルに貼り付けて利用できます
Copy DOT — Graphviz の digraph をクリップボードにコピーします。dot -Tpng にパイプしたり、.dot ファイルに保存して Graphviz でレンダリングできます

arm body 内の引用符・バックスラッシュ・改行はエスケープされるため、エクスポートしたテキストはどちらのレンダラーにも安全に渡せます。

ソース

let describe = result =>
  switch result {
  | Ok(value) => value
  | Error(_) => "fallback"
  }

Mermaid 出力

flowchart TD
  root["switch result"]
  n0["value"]
  root -->|"Ok(_)"| n0
  n1["fallback"]
  root -->|"Error(_)"| n1

ユースケース¶

網羅的なマッチのレビュー — ソースが何行に及んでも、すべての arm と body プレビューを並べて確認できる
コードパスの共有 — switch 全体を貼り付ける代わりに、Mermaid / DOT 画像を PR や設計書に貼って共有できる
新規コントリビュータのオンボーディング — 大きなパターン木を頭の中に保持せずとも、variant ロジックを追えるようサポートする

フローダイアグラムは純粋に構文ベースなので、LSP サーバーが起動していない状態でも動作します。

型影響プレビュー¶

Native

型変更の波及範囲を事前に見積もります。type 宣言にカーソルを置くと、プロジェクト全体の参照箇所が、果たしている役割（型注釈、variant コンストラクタ、パターン、フィールドアクセス）でタグ付けされて一覧表示されます。

開き方: View > Tool Windows > ReScript Type Impact、または Tools > Show Type Impact を使用します

仕組み¶

プロバイダはカーソル位置から PSI を上向きに辿って囲んでいる type 宣言を見つけ、ドット区切りのモジュールパス（Outer.Inner.t）を再構築します。次に PsiSearchHelper.processElementsWithWord をプロジェクトスコープで走らせて、その型のローカル名の出現箇所をすべて収集します。各ヒットは RescriptReferenceClassifier の小さなトークンベース・ヒューリスティックで分類され、直前の非空白文字を見て判定します:

: → type-ref（例: let x: t = ...）
. → field-access（例: user.t）
| → 直後の identifier が大文字始まりかつ ( が続けば constructor、それ以外は pattern
その他 → 大文字始まりの identifier は constructor、それ以外は unknown

unknown に分類される参照も一覧に残るため、曖昧なヒットがパネルから無言で消えることはありません。

ツールウィンドウのレイアウト¶

ツールバー: Refresh（現在の型に対する参照を再スキャン）
メインエリア: [kind] file.res:line preview 形式のエントリ一覧。ダブルクリックで該当の参照箇所にナビゲートする。[kind] プレフィックスは kind 別の bold 色で描画される — type-ref (青)、constructor (紫)、pattern (緑)、field-access (橙)、unknown (グレー) — ので、リスト中で支配的な参照種別を一目で判別できる
ステータスバー: Type.name: N reference(s) のサマリー。結果が切り詰められた場合は (showing first 200) が付加されます

ソフトキャップ¶

型あたり最大 200 件まで表示します。それを超えると切り捨て通知がステータスバーに表示されるため、対象の型を絞るか、より焦点を絞ったリファクタを使うかを判断できます。

ユースケース¶

型変更の規模見積もり — フィールドのリネームや variant ケース削除の前に、kind の分布を確認する
リファクタ前の監査 — type t = int のような型エイリアスをより複雑な型に差し替える前に、本当に少数の明確な場所でしか使われていないことを確認する
コードベースのオンボーディング — パネルをナビゲート可能な索引として、各ドメイン型がどこで消費されているかを見て回る

影響プレビューは純粋に構文ベースなので、LSP なしでも動作します。トークンベースの分類器は alias や open 文を辿れないため、kind ラベルは厳密な意味解析の答えではなく、ざっくりとしたガイドとして扱ってください。

Notebook 風 Worksheet¶

Native

既存のファイル全体評価型 .resw Worksheet と、行単位の REPL の中間に位置する、.resnb ファイル向けのセルベースエディタです。各セルは ReScript コード片と最後の実行結果を保持するため、試行錯誤を結果ごと保存・再オープンしたり、PR の説明や設計書向けに Markdown として共有したりできます。

開き方: .resnb 拡張子のファイルを作成または開きます。IDE はデフォルトの JSON ビューの代わりにセルベースエディタに切り替えます。

仕組み¶

.resnb ファイルは次の形式のプレーン JSON です:

{
  "version": 1,
  "cells": [
    {"code": "let x = 41", "lastOutput": ""},
    {"code": "Js.log(x + 1)", "lastOutput": "42"}
  ]
}

カスタム FileEditorProvider がこの JSON を NotebookDocument にパースして RescriptNotebookPanel に渡し、変更は in-memory document 経由で書き戻されるため、通常の保存ライフサイクルで永続化されます。セル実行は REPL ツールウィンドウと同じ RescriptReplExecutor を使用し、Run のたびにセルコードを一時 .res ファイルにラップして npx rescript build でコンパイル、生成された JavaScript を node で実行します。

不正な JSON は小さな警告ヘッダーで通知され、残りのエディタは空 Notebook にフォールバックするため、ユーザーがファイルへのアクセスを失うことはありません。

セル UI¶

上部: Cell ラベルと 3 つのアイコンボタン（Move Up、Move Down、Delete）
コードエリア: ReScript file type を渡した EditorTextField で構成されており、各セルが REPL 入力エリアと同じシンタックスハイライト・コード補完・折りたたみを得る — キーワード・型構築子・演算子・文字列リテラルがすべてエディタのカラースキームに従って色付けされる。
Run ボタン + 出力エリア: Run を押すとボタンが無効化され、プールスレッドでセルを評価し、捕捉した stdout/stderr が出力エリアに描画される。エラーは赤で表示される。セルの全色 (border、output 背景、エラー / 実行中前景) は JBColor(light, dark) ペアを使用しており、Light / Dark の両 IDE テーマでセルが十分なコントラストを得る。

ユースケース¶

調査 & POC — REPL 履歴をスクロールする代わりに、コードと観測した出力を並べて保持できる
バグ報告 & PR 説明 — 複数セルの探索結果をそのまま Markdown として GitHub issue に貼り付けられる
教育 & オンボーディング — 期待する出力を各例と一緒に残したチュートリアルを作成できる

制限事項（Phase 1）¶

セルは独立して評価されます — あるセルの let は次のセルからは見えません。状態共有は Phase 2 で対応予定です。
セルエディタは ReScript シンタックスハイライトを提供するが、セル内でのライブ LSP 診断は通常エディタが必要。キーストロークごとの赤波線が欲しい場合はノートブックの横に通常の .res ファイルを開いておくとよい。
リッチ出力（HTML、画像）には対応していません。出力領域はプレーンな等幅テキストです。

JS Interop Risk Map¶

Native

プロジェクトが型システムから抜け出している箇所をすべて一覧化します: %raw / %%raw ブロック、external 宣言、Obj.magic キャスト、@bs.* デコレータ。各エントリには粗いリスクレベルが付与され、レビュー時に確認すべき箇所の優先度がわかります。

開き方: View > Tool Windows > ReScript Interop Risk、または Tools > Show JS Interop Risk Map を使用します

仕組み¶

RescriptInteropScanner は FileTypeIndex 経由で GlobalSearchScope.projectScope 内のすべての .res / .resi ファイルを走査し、各ファイルを read action 内で読み込んで、各行を RescriptInteropClassifier に渡します。分類器は各行を単独で検査します:

行内のどこかに Obj.magic → HIGH リスク、kind obj-magic
%raw / %%raw → HIGH リスク、kind raw
external … + @bs.* / @send / @module / @scope / @val デコレータ → MEDIUM リスク、kind external
プレーンな external … → LOW リスク、kind external
単独の @bs.* / @send 等 → LOW リスク、kind bs-attr

ソフトキャップでパネルの応答性を確保します: 1 ファイルあたり 50 件、プロジェクト全体で 500 件。キャップに達するとステータスバーに (showing first 500) が表示されるため、結果が無言で切り捨てられることはありません。

ツールウィンドウのレイアウト¶

ツールバー: Refresh — プロジェクト全体のスキャンを再実行する
メインエリア: [risk/kind] file.res:line preview 形式のエントリ一覧。ダブルクリックで該当行にナビゲートする。各行は risk level に対応する 4 px 幅の左端色帯を持つ — HIGH 赤、MEDIUM 橙、LOW グレー — ので、[risk/kind] プレフィックスを読まずに severity を一目で判別できる
ステータスバー: 合計件数、（必要なら）切り捨て通知、kind ごとの内訳（raw=N obj-magic=N external=N bs-attr=N）

一覧はリスクの降順、続いてファイルパスと行番号でソートされ、表示が安定しています。

ユースケース¶

PR レビュー — 高リスク行から順に見て、安全でないキャストを精査する
ライブラリ移行 — 新しい @send / @module 構文へ移行が必要な @bs.* 箇所を追跡する
リファクタ計画 — runtime アップグレードを阻む少数の %raw ブロックを特定する

リスクマップは純粋に構文ベースなので、LSP なしでも動作します。行ベースのヒューリスティックでは特定の external が本当に安全かは判定できないため、全マッチを表示してレビュアーに判断を委ねる方針です。

Type Coverage Heat Map（型カバレッジヒートマップ）¶

Native

プロジェクト全体で、トップレベルの let 束縛のうちどれだけが明示的な型注釈を持ち、どれだけが推論に依存しているかを俯瞰するビューです。: int / : User.t のような数件の注釈を加えるだけで可読性とレビュー安全性が大きく向上するモジュールを発見するのに使います。

開き方: View > Tool Windows > ReScript Type Coverage

仕組み¶

RescriptTypeCoverageScanner は GlobalSearchScope.projectScope 内の .res ファイルをすべて走査し（2,000 ファイルでハードキャップ）、各ソースをレキサーベースの深さトラッカーでトップレベル let 宣言に分割して RescriptTypeCoverageClassifier に渡します。

束縛名と最初の depth-0 = の間に depth-0 の : トークンが現れたとき、classifier は ANNOTATED を返します。パラメータリスト、レコードリテラル、配列リテラルは depth カウンタを進めるので、それらの内部にある : トークンは誤って注釈として検出されません:

ソース	判定結果
`let x: int = 5`	ANNOTATED
`let f: (int, int) => int = (a, b) => a + b`	ANNOTATED
`let user: {name: string} = {name: "x"}`	ANNOTATED
`let x = 5`	INFERRED
`let f = (x: int) => x + 1`	INFERRED（注釈はパラメータのみ）
`let f = (x): int => x + 1`	INFERRED（注釈は戻り値のみで `=` の後ろにある）

パラメータや戻り値のみに注釈が付いた束縛は、v1 では意図的に INFERRED に分類しています。ファイルの読者にとって、束縛そのものはやはり推論に依存するためです。将来のリビジョンで「param-annotated」という別ティアを切り出す可能性があります。

ツールウィンドウのレイアウト¶

ツールバー: Refresh。
テーブル: 走査した各ファイルが 1 行で表示され、カラムは File / Total / Annotated / Inferred / Coverage % です。Coverage % セルは色分けされ、< 30% は赤、30〜69% は黄、≥ 70% は緑で表示されます。
デフォルトのソート: Coverage % の昇順なので、最も注釈を足したいファイルが上に並びます。任意のカラムヘッダをクリックして再ソートできます。
ステータスバー: <files> files, <bindings> bindings, <pct>% project coverage。スキャナが 2,000 ファイルのハードキャップに到達すると (truncated …) の注記が追加されます。

行をダブルクリックすると、そのファイルをエディタで開きます。

ユースケース¶

公開 API の引き締め — 推論に頼り切ったライブラリのエントリポイントやワークスペース境界を見つけ、公開前に明示的なシグネチャを足す。
リファクタリングの下準備 — ドメインモジュールを再構成する前にカバレッジを引き上げ、次の変更がソース上でドキュメント化された状態になるようにする。
オンボーディング — カバレッジの低いファイルを新規コントリビュータに渡し、型を 1 つずつ足す具体的なタスクとして担当してもらう。

制限事項¶

モジュール内部の let（module M = {{ … }} の内側の宣言）はカウントしません。トータルに寄与するのはファイルの depth-0 すなわち最上位の束縛のみで、軽量 PSI パーサがモデル化する範囲と一致します。
classifier は純粋に構文ベースで、言語サーバーには問い合わせません。そのため、コメントを挟みながら複数行に渡るような極端に異質なフォーマットでは稀に誤判定する可能性があります。境界事例の行は実ファイルを開いて確認してください。
let 宣言が 1 つも無いファイルは 100%（自明にカバーされた）として扱います。

PPX 展開ビュー¶

LSP Required

現在のファイルに適用された PPX マクロの展開出力を表示するツールウィンドウです。

開き方: View > Tool Windows > PPX Expansion

仕組み¶

PPX 展開ビューは現在のファイルに対して ReScript コンパイラの PPX プリプロセッサを実行し、変換された AST 出力を表示します。PPX が裏側で何のコードを生成するかを理解するのに役立ちます。

サポートされる PPX 属性¶

@react.component — 生成された React.createElement 呼び出しとコンポーネントラッパーを表示
@deriving(json) — 生成された toJson と fromJson 関数を表示
@deriving(accessors) — 生成されたフィールドアクセサ関数を表示
@genType — 生成された TypeScript 型定義を表示

ユースケース¶

PPX 動作のデバッグ — 生成されたコードが期待通りに動作しない理由を理解
学習 — PPX 属性がソースコードをどのように変換するかを確認
最適化 — パフォーマンスの観点から生成された出力をレビュー

アノテーションのハイライト¶

パネルは JEditorPane を使ってサマリを HTML としてレンダリングする。各 @annotation トークン (例: @react.component、@deriving、@module) はエディタのカラースキームのアノテーション属性から取得した色で太字 <span> に包まれ、周囲の英語説明文の中で目立つようになる。IDE テーマを切り替えると色が自動で更新される — 反映にはツールウィンドウを再オープン。

PPX マクロはソースファイルには見えないコードを生成します — このビューにより生成されたコードが可視化され、PPX 関連の問題のデバッグやコンパイラが実際に何を生成するかの理解に役立ちます。

コメント内コード評価¶

Native

ドキュメントコメントに埋め込まれた ReScript コード例をエディタから直接評価します。

/** ... */ ドキュメントコメントにコードブロックが含まれている場合、プラグインはコードを評価し結果をインラインで表示できます。ドキュメント内のコード例が正しく最新であることの検証に役立ちます。

使い方¶

ドキュメントコメント内にコード例を記述します
コードブロック内にキャレットを置きます
Code > Evaluate Comment Code を使用します（またはガターアクション）

/**
 * Adds two numbers.
 *
 * ```
 * add(1, 2)  // => 3
 * ```
 */
let add = (a, b) => a + b

プラグインはコードブロックを抽出してコンパイル・実行し、結果をインラインアノテーションとして表示します。

コメント内コード評価によりドキュメントの例が正しく最新であることを検証し、ユーザーを誤解させる前に古い・壊れたコードサンプルをキャッチします。

型シグネチャ検索¶

Native

Search Everywhere ダイアログ (Shift+Shift) で関数を型シグネチャから検索します。ユーザのクエリと各候補のシグネチャの双方を構造的な AST にパースし、RescriptTypeUnifier で照合するため、注釈された型が 実際にクエリの構造と一致する 宣言だけが結果に並びます — 単に同じ単語を含むだけの候補は除外されます。

使い方¶

Shift+Shift で Search Everywhere を開きます
ReScript Types タブに切り替えます
型シグネチャクエリを入力します（例: string => int、array<'a> => int、(int, int) => int）
プロジェクト内の .res / .resi ファイルから一致した宣言が name: signature (relative/path:line) の形式で表示され、マッチの強度順に並びます

クエリ構文¶

型シグネチャクエリは標準的な ReScript 型構文を使用します:

クエリ	マッチ対象
`string => int`	注釈された型がちょうど `string => int` の関数
`array<'a> => int`	第 1 引数が何らかの `array` で、戻り値が `int` の関数
`(int, int) => int`	int を 2 つ受け取り int を返す関数
`option<'a> => 'a`	第 1 引数が何らかの `option` で、戻り値型がその引数の型に一致する関数
`=> result<int, string>`	「T を返す」モード — 入力に関係なく、戻り値がその result である関数すべて

マッチ階層¶

unifier は各候補に対して 4 つのスコアのいずれかを出します。スコアが高い hit ほどリストの上位に並びます。

階層	条件	重み
`EXACT`	クエリと候補の構造が一致し、型名も完全に同じ	100
`TVAR_MATCH`	クエリ側の型変数 (`'a`) が候補の具体型を吸収	60
`PARTIAL`	「T を返す」クエリ (`=> T`) が候補の戻り値型に一致	30
`MISMATCH`	構造を一致させられない（ctor 不一致・arity 不一致・arrow と tuple の混在など）	0（結果から除外）

制限事項¶

注釈必須。 本機能は明示的な : T = … 注釈を持つ宣言のみを認識します。推論型 (例: let x = 5) は参加しないので、言語サーバ (Go to Symbol / Find Usages) を使うか、Type Coverage Heat Map で注釈不足のファイルを見つけてから検索してください。
ReScript 型のサブセットのみ。 レコード型 ({{name: string}})、ポリモーフィックバリアント ([#Foo | #Bar])、ラベル引数 ((~name: string) => unit) はパーサの対象外で、これらを含む候補は結果に並びません。
具体型のクエリは多相候補にはマッチしない。 int で検索しても let id: 'a => 'a には hit しません — クエリは「int を厳密に求める」と言っているのに、候補は多相だからです。unifier に具体型を吸収させたい場合は、クエリ側に型変数を書いてください。

検索結果のハイライト¶

結果行は name: signature (path:line) の形式で描画される。signature 部分は RescriptLexer でトークン化され、各トークンがエディタのカラースキームを経由して色付けされる — .res エディタ内と同じ属性でキーワード・型構築子・演算子・型変数・記号が色分けされるので、リストが灰色のイタリック塊ではなくエディタソースのように読める。

必要な関数の型は分かっているが名前が分からない場合、型シグネチャ検索により関数の形状から正しい関数を発見できます — ReScript のような型推論言語に自然にフィットします。

LSP 再起動アクション¶

LSP Required

Language Server が応答しなくなった場合や設定変更を反映する必要がある場合、Tools > Restart ReScript Language Server で再起動できます。

使用するタイミング¶

@rescript/language-server を手動で更新した後
LSP サーバーが応答しなくなった場合
サーバーの再起動が必要な LSP 関連の設定を変更した後

このアクションはプロジェクトが開いている場合にのみ利用可能です。現在の LSP サーバーインスタンスを停止し、新しいインスタンスを起動します。

Language Server が不良状態になった場合、素早い手動再起動が最も簡単な修正であり、IDE 全体を再起動する必要を回避できます。

LSP 初期化オプション¶

LSP Required

プラグインは ReScript Language Server にいくつかの初期化オプションを送信し、VSCode 拡張で利用可能な設定と一致させます。Settings > Languages & Frameworks > ReScript で設定します。

利用可能なオプション¶

設定	デフォルト	説明
シグネチャヘルプを有効化	On	`(` 入力時に関数パラメータ情報を表示
コンストラクタペイロードのシグネチャヘルプ	On	バリアントコンストラクタのペイロードにシグネチャヘルプを表示
プロジェクト設定キャッシュを有効化	On	プロジェクト設定をキャッシュして LSP の起動を高速化
Inlay Hints を有効化	Off	LSP 提供の Inlay Hints をエディタに表示（実験的）
Inlay Hints の最大長	25	Inlay Hint ラベルの最大文字数（0 = 無制限）
コンパイルステータスを有効化	On	LSP サーバーからコンパイルステータス通知を受信

これらの設定の変更は LSP サーバーの再起動後に有効になります（設定ダイアログで Apply をクリックすると自動的に再起動されます）。

これらの初期化オプションにより VSCode 拡張と同じ設定の柔軟性が得られ、シグネチャヘルプ、キャッシュ、インレイヒントなどの LSP 動作を好みに合わせて微調整できます。

LSP 状態のダンプ¶

LSP Required

Dump LSP State アクションは、トラブルシューティング用に ReScript Language Server の診断情報を表示します。

アクセス: Tools > Dump ReScript LSP State

表示内容¶

このアクションは以下の情報を収集して表示します:

LSP サーバーのステータスと数
ReScript プロジェクト検出情報
関連するプラグイン設定

ユースケース¶

LSP 問題のトラブルシューティング — LSP サーバーが実行中で正しく設定されていることを確認
バグレポート — プラグインメンテナーに問題を報告する際に LSP 状態を含める
デバッグ — LSP サーバーがどの設定を読み込んだかを確認

Dump LSP State は設定ファイルやログ出力を手動で検査することなく、Language Server の問題をトラブルシューティングしたりバグレポートに含めるために必要な診断情報を提供します。

定義済みコードスタイル¶

Native

プラグインは Settings > Editor > Code Style > ReScript > Set from... > Predefined Style > ReScript Standard で適用できる "ReScript Standard" 定義済みコードスタイルを登録します。

これにより標準的な ReScript の規約（2 スペースインデント、タブなし）に合わせてインデントとフォーマット設定をワンクリックで構成できます。

手動でインデントやタブ/スペースの設定を行うには、Settings > Editor > Code Style > ReScript に移動してください。

定義済みコードスタイルによりワンクリックで正しい ReScript フォーマット規約が適用され、インデント設定を手動で構成する必要がありません。

要素の説明¶

Native

プラグインは Find Usages、Safe Delete、リファクタリング確認などの IDE ダイアログで使用する ReScript 要素の人間が読みやすい説明を提供します。

例えば、関数に Safe Delete を使用すると、確認ダイアログには以下のように表示されます:

Delete function 'greet'?

汎用的な "Delete element" メッセージではなく上記のように表示されます。これは let バインディング、type 宣言、module 宣言、external 宣言、exception 宣言に適用されます。

IDE ダイアログでの記述的な要素名によりリファクタリングの確認が明確になります — 汎用メッセージではなく「関数 'greet' を削除」と表示され、偶発的な削除のリスクが減ります。

ビルドウォッチ自動開始プロンプト¶

Native

ReScript プロジェクトを開くと、プラグインが ReScript ウォッチビルド（rescript watch）の開始を提案するバルーン通知を一度表示します。

表示される条件¶

プロンプトはプロジェクト起動時に以下の条件を満たす場合に表示されます:

プロジェクトに rescript.json が含まれている
ReScript CLI（rescript）が node_modules/.bin/ に見つかる
現在の IDE セッションでプロンプトがまだ非表示にされていない

通知アクション¶

アクション	説明
Start Build Watch	Run Configuration 経由で `rescript watch` を起動します
Don't ask again	この IDE セッションでプロンプトを非表示にします

Start Build Watch をクリックすると、ライブリコンパイルビルドプロセス付きの Run ツールウィンドウが開きます。

ビルドウォッチプロンプトにより、プロジェクトを開いた瞬間からライブコンパイルフィードバックを受け取り始めることができ、ビルドコマンドを手動で実行することを覚えておく必要がありません。

REPL¶

Native

IDE 内で直接 ReScript コードスニペットを実行するためのインタラクティブな Read-Eval-Print ループです。

開き方: View > Tool Windows > ReScript REPL

使い方¶

REPL ツールウィンドウを開きます
下部の入力エリアに ReScript コードを入力します
Run をクリックして実行します
上部の出力エリアに結果が表示されます
Clear をクリックして出力をリセットします

式の処理¶

REPL は出力のためにシンプルな式を自動的にラップします:

let バインディング、type/module 宣言、open ステートメントはそのまま使用されます
既に Js.log または Console.log を含むコードはそのまま使用されます
シンプルな式は自動的にラップされます: 1 + 2 は Js.log(1 + 2) になります

// Input: simple expression
1 + 2
// Output: 3

// Input: let binding
let greeting = "Hello"
Js.log(greeting)
// Output: Hello

仕組み¶

各実行は分離されています:

ユーザーコードを含む一意の名前の一時 .res ファイルを作成します
npx rescript build でコンパイルします
コンパイルされた JavaScript を node で実行します
出力エリアに stdout/stderr を表示します

実行ごとに、コンパイル前に専用のソース・JavaScript・ソースマップのパスを確保します。コンパイルや実行が失敗した場合も、その実行で作成したファイルだけを削除します。既存のプロジェクトファイルとシンボリックリンクは保持されます。

要件¶

ReScript CLI（rescript）がプロジェクトにインストールされている必要があります
Node.js が PATH に存在する必要があります

制限事項¶

実行間で永続的な状態はありません（各実行は分離されています）
コンパイルと実行に 30 秒のタイムアウトがあります

REPL はファイルの作成、コンパイル、実行なしに式のテストや API の探索ができるインタラクティブなフィードバックループを提供します — ReScript の学習や素早い仮定の検証に最適です。

Worksheet モード¶

Native

Worksheet ファイル（.resw）では ReScript コードを記述し、各トップレベル式が評価されて結果がインラインで表示されます。

使い方¶

.resw 拡張子で新しいファイルを作成します
トップレベル式を含む ReScript コードを記述します
各式が評価され、結果がインラインコメントとして表示されます

let x = 1 + 2
// => 3

let greeting = "Hello, " ++ "World!"
// => Hello, World!

type color = Red | Green | Blue
// (type declarations are skipped)

式のグルーピング¶

Worksheet は波括弧と括弧の深さを追跡することで複数行の式を理解します。空行、コメント、型宣言、モジュール宣言、open ステートメントは評価時にスキップされます。

要件¶

ReScript CLI（rescript）がプロジェクトにインストールされている必要があります
Node.js が PATH に存在する必要があります

Worksheet はすべての式の結果がインラインで表示されるノートブックのような体験を提供し、アルゴリズムのプロトタイピング、変換のテスト、ドキュメント例の検証に最適です。

スクラッチファイル¶

Native

プロジェクトにファイルを追加せずに、IDE の Scratches パネルで素早い実験用の一時的な ReScript ファイルを作成します。

使い方¶

File > New > Scratch File を開きます（macOS では Cmd+Shift+N）
言語リストから ReScript を選択します
デフォルトテンプレート付きの新しいスクラッチファイルが開きます:

// ReScript Scratch File
let result = "Hello"
Js.log(result)

機能¶

完全な ReScript シンタックスハイライトと言語サポート
プロジェクトディレクトリ外に保存されるスタンドアロンファイル
通常の .res ファイルと同様にコンパイル・実行できます
プロトタイピング、ライブラリ関数のテスト、ReScript 構文の学習に便利です

スクラッチファイルはプロジェクトにファイルを追加したりソースツリーを汚すことなく、素早い実験のための使い捨てワークスペースを提供します。

Call Hierarchy¶

Native

関数の呼び出しグラフを表示し、何がその関数を呼び出すか（Callers）と、その関数が何を呼び出すか（Callees）の両方を表示します。

開き方: 関数名にカーソルを置き、Ctrl+Alt+H（macOS では Cmd+Alt+H）を押します

表示モード¶

階層ブラウザには 2 つのタブがあります:

Callers（デフォルト）--- 選択した関数を呼び出すプロジェクト内のすべての関数を表示します。テキストベースの検索でプロジェクト全体を検索します。

Callees --- 選択した関数が呼び出すすべての関数を表示します。同じファイル内の関数本体をスキャンして検出します。

ナビゲーション¶

ノードをダブルクリックして関数のソースに移動します
Previous/Next ボタンを使用して関数間をナビゲートします
ノードはアルファベット順にソートされます

仕組み¶

Call Hierarchy は LSP ではなく PSI ベースのテキスト検索を使用します:

Callers: プロジェクト内のすべてのファイルで関数名のテキスト出現を検索します
Callees: 関数本体の識別子トークンをスキャンし、同一ファイル内の宣言と相互参照します

制限事項¶

テキストベースのマッチング --- エイリアスやモジュール修飾された呼び出しは見つからない場合があります
Callees は同一ファイル内でのみ検出されます（ファイル間の Callee 検出はありません）
.res ファイル内の let および external 宣言に対して動作します

関数の呼び出しチェーンを理解することはリファクタリングやデバッグ時に不可欠です — このビューはコードを手動でトレースすることなく、関数を誰が呼び出し何を呼び出すかを明らかにします。

高度な機能¶

モノレポ対応¶

自動検出パイプライン¶

手動上書き¶

制限事項¶

Code Lens¶

仕組み¶

設定¶

要件¶

コンパイル済み JavaScript プレビュー¶

自動更新の動作¶

分割表示のセットアップ¶

ツールバーアクション¶

ユースケース¶

モジュール階層¶

2 つの表示モード¶

ナビゲーション¶

Inlay Hints¶

設定¶

Code Lens との違い¶

PPX アノテーションヒント¶

rescript.json の JSON Schema¶

自動補完されるフィールド¶

機能¶

Markdown コードフェンスのハイライト¶

統合メカニズム¶

要件¶

JavaScript Injection in %raw()¶

言語インジェクションメカニズム¶

利用できる機能¶

要件¶

RegExp Injection in %re()¶

言語インジェクションメカニズム¶

利用できる機能¶

要件¶

インジェクトされた言語のフォーマット¶

Grazie 統合¶

Index Pattern Builder¶

Element Signature Provider¶

プロジェクトウィザード¶

手順¶

利用可能なテンプレート¶

生成されるプロジェクト構造¶

テンプレートの詳細¶

バリデーションライブラリ¶

プロジェクト作成後¶

開発者体験の向上¶

Vite+ ツールチェイン (Vite + React、Electron、Monorepo)¶

ファイルテンプレート¶

使い方¶

利用可能なテンプレート¶

テンプレートのカスタマイズ¶

.d.ts バインディング生成¶

使い方¶

サポートされる構文¶

型マッピング¶

要件¶

制限事項¶

カラープレビュー¶

VCS Code Vision¶

パッケージ依存関係¶

Quick Documentation¶

Safe Delete¶

名前候補の提案¶

Reader Mode¶

TODO インデキシング¶

Open ステートメントインデックス¶

Project View の拡張¶

自動インポートオプション¶

式の型表示¶

Type Info ツールウィンドウ¶

仕組み¶

シンタックスハイライト¶

ユースケース¶

要件¶

LSP 自動インストール¶

通知アクション¶

GitHub エラーレポーター¶

仕組み¶

プライバシー¶