TypeScriptの深淵：`lib`設定が語る「実行環境」という名の現実
フロントエンドのアーキテクトとして多くのコードベースを渡り歩いてきたが、未だに「なんとなく `tsconfig.json` の `lib` をデフォルトのままにしている」というプロジェクトに出会うと、少し背筋が凍る思いがする。
多くのエンジニアは「型定義の読み込み設定」程度に考えているかもしれないが、`lib` の設定は、君たちのアプリケーションがどの程度の「実行環境の現実」を許容し、どの程度の「ランタイムの負荷」を許すかという、設計上の宣言そのものだ。
今回は、この地味だが極めて強力なオプションを通じて、堅牢なアーキテクチャを築くための「大人のTypeScript」を語ろう。
—
1. 「デフォルト」という甘えと、型安全性の腐敗
TypeScriptのデフォルト設定に甘えていると、実行環境に存在しないAPIが型補完されてしまう。「動くからいいや」で済ませていると、やがて `window` オブジェクトの肥大化や、不要なポリフィルによるバンドルサイズの肥大化、そして何より「本来あるはずのない環境への依存」という技術的負債が蓄積する。
例えば、Node.jsで動かすバックエンドのコードに `DOM` ライブラリが含まれているとどうなるか。`document` や `HTMLElement` が型として見えてしまい、本来防ぐべきDOM操作の誤用をコンパイラが見逃してしまう。これはバグの温床だ。
2. `lib` を絞り込むことによる「メモリ効率と最適化」の真実
`lib` を明示的に指定することは、「TypeScriptが解釈する世界を最小化する」ことと同義だ。
{
“compilerOptions”: {
/
- 不要な型定義を排除し、コンパイル時のメモリ消費を抑える。
- 特に大規模プロジェクトでは、不要なDOM APIの型を読み込まないだけで
- 型チェックのキャッシュ効率が目に見えて向上する。
/
“lib”: [“ESNext”, “DOM”, “DOM.Iterable”]
}
}
ここで重要なのは、`DOM` や `DOM.Iterable` を本当に必要としているかという点だ。もし君たちがフロントエンドのロジック層（ビジネスロジック）をピュアなTypeScriptで記述しているなら、ロジック層の `tsconfig.json` からは `DOM` を切り離すべきだ。
ロジック層で `window` や `document` に直接触れるコードを型的に排除できれば、テストの際、JSDOMのような重いモックを無理やり挿入しなくても、純粋な値と関数だけでユニットテストが完結する。これが堅牢なアーキテクチャの第一歩だ。
3. 非同期処理とランタイムの競合を回避する
最近のモダンなフレームワーク（Next.jsやViteなど）は `lib` を自動生成してくれるが、そこに隠された「見えないリスク」がある。特に、`ESNext` を指定した場合、将来的にブラウザに実装される最新の非同期API（例えば `Iterator Helpers` や `Temporal` など）が先行して型定義されることがある。
これらは便利だが、ポリフィルなしで実行環境にデプロイすると、ランタイムで当然のように `ReferenceError` を引き起こす。
// 将来のAPIを lib に含めると、コンパイラは「ある」と信じ込む
// しかし、ターゲットブラウザのエンジンが追いついていないと…
const stream = (data as any).toSorted();
// もし runtime にこのAPIがない場合、ここでクラッシュする。
// lib の指定と、ターゲットとなるブラウザのサポート状況は
// 常に同期していなければならない。
4. 戦略的アーキテクチャ：環境ごとの多層構造
現場のベストプラクティスとしては、`tsconfig.json` を継承（`extends`）させて、層ごとに `lib` を使い分けるのが正解だ。
// tsconfig.base.json
{
“compilerOptions”: {
“lib”: [“ESNext”] // 基盤はピュアなJS機能のみ
}
}
// tsconfig.app.json (クライアントサイド)
{
“extends”: “./tsconfig.base.json”,
“compilerOptions”: {
“lib”: [“ESNext”, “DOM”, “DOM.Iterable”] // ブラウザAPIが必要な層だけ継承して追加
}
}
こうすることで、ドメインロジックに「DOM依存」という汚染が混入するのを、コンパイラレベルで物理的に防ぐことができる。
最後に：エンジニアとしての矜持
`lib` の設定をいじることは、ただの「設定作業」ではない。それは、君たちがコード上で定義する「型」という名の契約が、どの土台の上で実行されるべきかを明確にする、アーキテクトとしての宣言だ。
「とりあえず動く」コードを書くのはジュニアでもできる。しかし、「どの環境で、どのAPIが使えるか」を型レベルで厳密に管理し、ランタイムエラーの可能性をコンパイル時に削ぎ落とすことこそが、フロントエンドの伝説的なスペシャリストに求められる仕事だ。
君たちの `tsconfig.json` は、今日からより厳格で、より透明性の高いものになるはずだ。さあ、コードベースをクリーンに保ち、明日もまた、堅牢なWebアプリケーションを世に送り出そう。
コメント