【実務・中級編】Sublime Textで大規模プロジェクトの「検索インデックス」を劇的に高速化する隠し設定 – 軽量・高機能テキストエディタ生産性向上バイブル

Sublime Textで数百万行のモノレポを「爆速」にする:検索インデックス最適化の深淵

モノレポ環境で `Find in Files` を実行した際、数秒間エディタがフリーズする――。多くのエンジニアがこれを「Sublime Textの限界」と諦めていますが、それは大きな誤解です。Sublime Textは、適切に調教すれば数百万行のコードベースであっても、IDEとは比較にならないほどのレスポンスを維持できるポテンシャルを持っています。

本稿では、単なる設定値の変更を超え、OSカーネルとエディタの挙動を同期させるレベルの「高機能化チューニング」を伝授します。

—

1. インデックス汚染の徹底排除:`index_exclude_patterns` の再定義

Sublime Textの検索が重い最大の原因は、`node_modules` や `build`、`vendor` フォルダなど、「検索対象にする必要がない巨大な自動生成物」がインデックス対象に含まれていることです。

多くのユーザーは `index_exclude_patterns` にデフォルト値しか入れていませんが、プロジェクトのルートにある `.sublime-project` ファイルでこれを制御するのがプロの作法です。

{
“folders”: [
{
“path”: “.”,
// インデックスから除外するパターン。正規表現ではなくglob形式で記述
// ログ、ビルド成果物、テストで生成されるデータ、依存関係を徹底的に除外
“index_exclude_patterns”: [
“.log”,
“/node_modules/“,
“/dist/“,
“/build/“,
“/tmp/“,
“/vendor/“,
“/.git/”
]
}
],
// インデックス作成をマルチコアに割り当てる設定。
// CPUコア数 – 1 を設定するのが安定稼働のコツ。
“index_workers”: 7
}

なぜこれが必要か:
Sublime Textはファイル変更を監視する際、`index_exclude_patterns` にマッチしたディレクトリに対しても `inotify` イベントを消費します。Linuxカーネルの監視上限 (`fs.inotify.max_user_watches`) を圧迫しないためにも、これらを物理的にスキャン対象から外すことは、OSレベルでのレスポンス向上に直結します。

—

2. OSの限界を突破する:inotifyの制限緩和(Linuxユーザー向け)

モノレポが巨大化すると、Sublime Textがどれだけ最適化されても、OSが「監視すべきファイルの数」に制限をかけているため、変更検知が遅延します。

以下のコマンドで現在の制限を確認し、プロジェクト規模に合わせて拡張してください。

現在の監視上限を確認
cat /proc/sys/fs/inotify/max_user_watches

524288(512k)程度まで引き上げるのがモノレポ開発の標準
echo “fs.inotify.max_user_watches=524288” | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

これを適用するだけで、Sublime Textのインデックス再構築速度が劇的に変わります。

—

3. 生産性を極限まで高める「神プラグイン」構成

Sublime Textを「単なるテキストエディタ」から「AIエンジンを搭載したIDE」へと昇華させる構成を紹介します。

1. LSP (Language Server Protocol): Sublime Textを完全な言語サーバークライアントにします。VSCodeと同等の静的解析を、軽量なメモリフットプリントで実現可能です。
2. LSP-typescript / LSP-intelephense: 各言語のサーバーを接続。設定で `hover` や `completion` のレスポンスを細かく調整できます。
3. AdvancedNewFile: ファイル作成時のパス入力補完を爆速化します。モノレポ内の深い階層にファイルを作る際に必須です。

—

4. チーム開発における「設定の共有化」ルール

プロジェクトごとに `.sublime-project` ファイルをGit管理するのは基本ですが、個人の環境設定(キーバインドなど)と混ざるのを防ぐため、以下のディレクトリ構造を推奨します。

.
├── .sublime-project # プロジェクト固有のパス設定とインデックス設定
├── .sublime-workspace # Git除外推奨(個人のエディタ状態)
└── .vscode/ # もしチームでVSCodeも混在する場合、LSPの設定を共通化する

プロのテクニック:
`Project: Edit Project` から設定を開き、`settings` セクションに `tab_size` や `translate_tabs_to_spaces` を強制的に記述してください。これにより、誰が開いてもインデントが崩れない「エディタ依存のコードフォーマット事故」を防げます。

—

5. 現場で使える「隠し」キーボードショートカット

知っているか否かで、1日あたりの操作時間が数分変わります。

  • `Ctrl + Shift + F` (Find in Files): 検索対象を `Where` フィールドで `` に限定する癖をつけてください。検索範囲が絞られるだけでインデックスの探索コストが激減します。
  • `Ctrl + P` (Goto Anything): ファイル名の後に `@` を付けると関数リスト、`#` を付けるとシンボル検索が走ります。インデックスが効いている状態なら、数万ファイルからでも0.1秒以内に目的のメソッドへ飛べます。
  • `Ctrl + Shift + P` (Command Palette): ここで `LSP: Restart Language Server` を登録しておきましょう。インデックスが稀に破損した際、エディタを再起動せずとも数秒で復旧できます。

—

まとめ:アーキテクトからの提言

Sublime Textが「古い」と感じるのは、その真価を引き出せていないだけです。
プロジェクトの構造に合わせて `index_workers` を割り当て、`inotify` の壁を取り払い、LSPで現代的な静的解析を付与する。これを行うだけで、あなたの手元には「VSCodeの機能性を持ちつつ、IDE特有の重さから解放された、最も指に馴染む高速環境」が完成します。

開発ツールは「与えられたものを使う」のではなく、「環境に合わせてチューニングする」のがプロのエンジニアの流儀です。ぜひ今日から、あなたのプロジェクトの `.sublime-project` を見直してみてください。

タイトルとURLをコピーしました