巨大モノレポを制する：HHVM型チェッカーの深淵と「分割」の技術的真実
Hackの型チェッカー（`hh_client` / `hh_server`）は、単なる静的解析ツールではない。あれは、数百万行に及ぶコードベースの「意味論的整合性」をリアルタイムで担保し続ける、極めて高度な増分コンパイル・エンジンである。
大規模モノレポにおいて、型チェックが「終わらない苦行」と化すのは、アーキテクチャの敗北だ。今回は、HHVMの型チェッカーの内部挙動を解剖し、いかにしてコードを分割し、型システムの負荷を物理的に「切り分ける」か、その極限の戦略を語る。
—
1. 型チェッカーの「重み」を定義する：グラフの計算量
HHVMの型チェッカーは、コードを抽象構文木（AST）としてだけでなく、依存関係の有向非巡回グラフ（DAG）として管理している。型チェックが遅延する最大の要因は、「変更が伝播する依存範囲の広さ」だ。
ある型定義を変更した際、型チェッカーは以下のプロセスを辿る。
1. Invalidation: 依存関係グラフに基づき、影響を受けるシンボルのエントリを無効化する。
2. Re-check: 無効化されたノードを再帰的に再評価する。
ここで重要なのは、「抽象度の高い型（`shape`や`class`のインターフェース）」をモノレポの中央に配置すると、変更のたびにグラフ全体が再計算の対象になるという事実だ。
2. アーキテクチャの戦略：型の境界（Boundary）を物理的に分離する
型チェックを爆速化するための唯一の解は、「依存関係の疎結合化」ではなく「型の名前空間による物理的分離」である。
推奨戦略：`lib`層と`app`層の完全な型分離
大規模なモノレポでは、`common/types`のような巨大な中央集権型定義ファイルを避けるべきだ。代わりに、以下の構造を採用する。
- Contract Isolation: ドメイン境界をまたぐ型は、`__EnableUnstableFeatures(‘like-types’)`等を駆使して、一時的に「Like-types」として許容し、境界での型チェックを限定的にする。
- Module-based Type Checking: HHVMの `modules` 機能を利用し、型の可視性を制御する。これにより、型チェッカーは「モジュール外部へ露出していない内部的な型」を、グラフの解析対象から事実上除外できる。
// 良い例：モジュール境界での型分離
// このモジュール外に露出する型を極限まで絞り込む
module UserDomain {
// 外部から隠蔽された内部型。チェッカーはこのスコープ内のみで再計算すれば良い
internal type TUserInternal = shape(‘id’ => int, ‘secret’ => string);
public function getUser(): TUserPublic {
// 戻り値の型は公開されたものに限定し、依存関係を最小化する
return / … /;
}
}
3. メモリ管理と型チェックの最適化
`hh_server`は、型チェックの過程で大量のメモリを消費する。大規模なプロジェクトでは、型チェッカーが使用するメモリ（Shared Memory）が物理メモリを圧迫し、カーネルレベルのメモリ管理（ページフォールト）がボトルネックになる。
型チェッカー高速化のTips
- `hhconfig`による除外設定の徹底: `[include_paths]`および`[exclude_paths]`を最小化せよ。自動生成コードやテストコードは、型チェックの頻度を下げるべきだ。
- `hh_server`の再起動戦略: 長時間稼働する`hh_server`は、ヒープの断片化によりパフォーマンスが劣化する。CI/CDパイプラインにおいては、一定のタスク完了ごとにサーバを再起動する「クリーンな状態」を維持する方が、結果的にトータルコストは低い。
4. 厳格な「Strict Mode」を維持するためのコード分割技術
`strict`モードは、妥協なき整合性を保証する。しかし、分割されたコード間で型情報を共有しようとすると、往々にして`Any`型への逃げ道を作りたくなる。それを防ぐのが「Interface-driven Development」だ。
実装クラスを直接依存させるのではなく、`interface`のみをモジュール間で共有するように分割する。
// 悪い例：具象クラスに依存しており、変更が伝播する
// class PaymentProcessor extends AbstractProcessor { … }
// 良い例：インターフェースによる型の切り離し
interface IPaymentProcessor {
public function process(PaymentRequest $req): PaymentResult;
}
// これにより、IPaymentProcessorの実装を変更しても、
// これを利用する側の型チェックは、インターフェース定義が不変である限り再計算をスキップできる。
結論：型システムは「静的な設計」ではない
Hackの型システムを使いこなすということは、コンパイラがどのようにメモリを使い、どう依存関係をトラバースするかという「実行時の挙動」を把握することと同義だ。
コードを分割する際、単にディレクトリを分けるのではない。「型情報の伝播経路」を設計するのだ。型の境界を正しく設計し、依存関係のグラフを細分化すれば、HHVMの型チェッカーは真の力を発揮し、大規模なモノレポであっても数秒で整合性を保証してくれるだろう。
型を信じろ。ただし、型チェッカーのコストを制御するのは、お前自身だ。