TypeScript を使い始めたとき、strict モードを有効にすると大量のエラーが出てうんざりした経験がある方も多いでしょう。しかし、それらのエラーの多くは実際に実行時バグになり得るものです。strict は「うるさい型チェッカー」ではなく「事前のコードレビュー」です。
strict が有効にするチェック
- strictNullChecks: null/undefined を型として扱う
- noImplicitAny: 暗黙の any を禁止
- strictFunctionTypes: 関数の型の反変・共変を厳密にチェック
- strictPropertyInitialization: クラスプロパティの未初期化を禁止
- useUnknownInCatchVariables: catch の変数を unknown 型にする
最も頻出するエラーと対処法
strict 有効化後に最もよく遭遇するのは「Object is possibly undefined」です。これは Optional Chaining (?.) や Non-null Assertion (!) で対処できますが、後者は型システムを騙すものなので乱用は禁物です。
typescript
// NG: Non-null Assertion の乱用
const name = user!.profile!.name!;
// OK: Optional Chaining + フォールバック
const name = user?.profile?.name ?? "Anonymous";
// OK: 早期リターンで型を絞り込む
if (!user || !user.profile) return null;
const name = user.profile.name; // ここでは string に絞られる既存プロジェクトへの段階的導入
既存のプロジェクトに一気に strict を有効にするのは大変です。ts-migrate のようなツールや、チェックを一つずつ有効にしていく段階的アプローチが現実的です。新しいファイルから strict を守る運用でも効果があります。
長期的にみれば、strict モードを有効にしたプロジェクトはそうでないプロジェクトよりもバグが少なく、リファクタリングが安全で、チームの生産性が高い傾向があります。初期コストを惜しまないでください。