TypeScriptの深淵：`watchOptions`で「開発体験」という名の戦場を制圧する
フロントエンドのアーキテクチャを語る上で、ビルドツールやコンパイラの「監視モード」を軽視する者は、いずれ巨大な技術的負債という名の墓穴を掘ることになる。
多くのエンジニアは `tsc –watch` を単なる「保存時に再コンパイルしてくれる便利な奴」程度に考えているかもしれない。だが、大規模なモノレポや、数千のモジュールが絡み合うプロジェクトにおいて、この設定は「開発効率」と「マシンの熱暴走」、そして「エディタの応答性」を左右する生死の境界線だ。
今日は、`tsconfig.json` の片隅に追いやられがちな `watchOptions` について、現場で血を流しながら得た知見を共有しよう。
—
なぜ `watchOptions` が「上級エンジニア」の嗜みなのか
OSのファイル監視API（`inotify`や`FSEvents`）は万能ではない。特に、巨大な `node_modules` や、生成される一時ファイル、ログファイルが混在する環境では、コンパイラは「何を監視し、何を無視すべきか」の判断にリソースを浪費する。
もし君が VSCode で「型定義がいつまでも反映されない」「CPU使用率が常に高止まりしている」というストレスを感じているなら、それはOSの通知バッファが溢れているか、TypeScriptの監視ロジックが無限ループに近い再帰的な走査を繰り返している証拠だ。
実践的 `watchOptions` 構成案
以下は、中〜大規模プロジェクトにおいて、パフォーマンスと安定性を最大化するための構成例だ。
{
“compilerOptions”: {
/ … 既存の設定 … /
},
“watchOptions”: {
// OSのネイティブ監視が不安定な環境や、ネットワークドライブ上では ‘fixedPollingInterval’
// もしくは ‘dynamicPriorityPolling’ が必須。CPU負荷と応答性のトレードオフを調整する。
“watchFile”: “useFsEvents”,
// ディレクトリ監視を最適化。大規模プロジェクトでは特に重要。
“watchDirectory”: “useFsEvents”,
// 頻繁に書き換わるログや一時ファイルを監視対象から除外。
// これを怠ると、再コンパイルが無限ループする地獄を見る。
“excludeDirectories”: [“/node_modules”, “/dist”, “/tmp”, “/logs”],
// 連続するファイル保存をまとめ上げ、無駄な再コンパイルを抑制する。
“synchronousWatchDirectory”: false,
// コンパイルの「揺らぎ」を制御する。
“fallbackPolling”: “dynamicPriorityPolling”
}
}
深掘り：なぜこの設定が必要なのか
1. `watchFile` / `watchDirectory` の選択戦略
デフォルトの `useFsEvents` はOSのネイティブAPIを叩くため、非常に高速だ。しかし、Linuxの `inotify` 制限数に達したり、Dockerコンテナ越しでファイルの変更イベントが正しく伝搬しない場合、途端に機能しなくなる。
もし「Docker環境でライブリロードが効かない」という事態に陥ったら、迷わず `fixedPollingInterval` への切り替えを検討すべきだ。確かにCPUは食うが、「動かないツール」より「少し重いツール」の方が、ビジネス現場では圧倒的に価値がある。
2. `excludeDirectories` の真実
意外と見落とされがちなのが、`excludeDirectories` の重要性だ。特に、ビルド成果物を `dist` や `out` といったディレクトリに出力している場合、コンパイラがその出力を「新たなソースファイル」と誤認し、再コンパイルをトリガーする「再帰的ビルド地獄」が発生することがある。これを物理的に遮断するのは、アーキテクトとしての最低限の防衛線だ。
3. `fallbackPolling` による非同期の競合回避
`dynamicPriorityPolling` は、頻繁に変更されるファイルには優先的にリソースを割り当て、たまにしか変更されないファイルは監視頻度を下げるという、賢いアルゴリズムだ。大規模なコードベースにおいて、全ファイルを等しく監視するのはメモリの無駄でしかない。この設定は、特にVSCodeのメモリ消費量を抑え、エディタの入力遅延（インプットラグ）を改善する鍵となる。
—
アーキテクチャの視点：開発体験（DX）もまた「設計」である
フロントエンドエンジニアの仕事は、プロダクトのコードを書くことだけではない。「いかに開発環境を高速に保ち、チーム全員が脳のスタックを消費せずにコードに集中できるか」という環境の設計もまた、極めて高度なエンジニアリングスキルだ。
`watchOptions` を適切に設定することは、コンパイラの挙動をコントロールし、マシンリソースを最適化し、そして何より「待ち時間」という無駄なコストを削ぎ落とす行為である。
もし君が、ただデフォルト設定を放置しているだけなら、今日この設定を見直してほしい。わずか数行の記述で、君のPCのファンは静かになり、型チェックのフィードバックループは劇的に速くなるはずだ。
技術は常に「詳細」に宿る。公式ドキュメントをなぞるだけではなく、その裏側で何が起きているのかを想像し、環境そのものをハックしていく。それこそが、この泥臭いフロントエンドの最前線で生き残るための、唯一の道だ。
コメント