【実務・中級編】 tsconfigのstrictNullChecksオプション – TypeScript実践ガイド

`strictNullChecks` がないTypeScriptは、ただの「少し賢いJavaScript」に過ぎない

いいか、まず厳しい現実から伝えよう。もし君が現在開発しているプロジェクトの `tsconfig.json` で `strictNullChecks` が `false` になっているなら、今すぐそれを `true` に変える作業をタスクの最優先事項に入れてくれ。

TypeScriptを導入する最大の動機は「型による防御」だ。しかし、`null` や `undefined` がどこへでも代入できてしまう設定(`false`)では、ランタイムで「Cannot read property ‘x’ of null」という、エンジニアがこの世で最も憎むべきエラーと一生付き合うことになる。

今日は、TypeScriptの型安全性の心臓部とも言える `strictNullChecks` について、現場のリアルな視点から解説する。

—

なぜ `strictNullChecks` が「型安全の根幹」なのか

`strictNullChecks: false` の世界では、全ての型は `null` や `undefined` を内包していると見なされる。つまり、`string` 型と定義した変数に、平気な顔をして `null` が代入できてしまうんだ。

これは、コンパイラが「お前が定義した型は信じない」と言っているのと同じだ。一方、`true` にすると、型システムは極めて誠実になる。「`string` は文字の集まりであって、`null` ではない」という厳格な契約が結ばれる。これが、TypeScriptが真にTypeScript足る所以だ。

ブラウザの裏側で起きていること

ブラウザのJavaScriptエンジン(V8など)にとって、`null` や `undefined` は「何もないこと」を示す値だ。しかし、これらはメモリ上では明確な「値」として存在する。

`strictNullChecks: false` だと、TypeScriptコンパイラは「この変数には `null` が入るかもしれないから、コード側で都度チェックしてね」という警告を一切出さない。その結果、JavaScriptエンジンは「何も入っていない場所」に対してプロパティアクセスを試み、メモリ上の不正な領域を参照しようとしてクラッシュする。

TypeScriptの型チェックは、この「実行時のメモリ破壊や未定義参照」を、コンパイル前に食い止めるためのシールドなんだ。

—

実践:現場で使うべき「安全な型定義」の書き方

では、実際に現場でどう扱うのがベストか。`strictNullChecks: true` の世界では、「あるかもしれない」を明示的に扱うのが作法だ。

/

  • 現場でよくある「APIから返ってくるユーザー情報」の型定義

/
interface User {
id: number;
name: string;
// プロフィール画像は設定されていない場合(null)があり得る
avatarUrl: string | null;
}

function displayUserName(user: User | undefined) {
// 1. まずは undefined チェック
if (!user) {
console.log(“ユーザーがいません”);
return;
}

// 2. ここで user は User 型に絞り込まれる (Type Narrowing)
console.log(`Hello, ${user.name}`);

// 3. avatarUrl の場合、null チェックを忘れるとコンパイルエラーになる
// これこそが strictNullChecks の恩恵だ
if (user.avatarUrl !== null) {
console.log(`アバターURL: ${user.avatarUrl.toLowerCase()}`);
} else {
console.log(“アバターは未設定です”);
}
}

// 現場で重宝する「非空アサーション」は最後の手段
const element = document.getElementById(“app”)!; // どうしてもnullじゃないと確信できる時だけ使う

—

チームへのアドバイス:運用を変えるために

もし今、`strictNullChecks: false` の巨大なレガシープロジェクトを抱えているなら、一気に `true` にするのは自殺行為だ。数千のコンパイルエラーに埋もれて、チームの士気は地の底まで落ちるだろう。

おすすめのステップはこうだ:

1. 新規ファイルから適用: `tsconfig` をいじる前に、まずは新規作成するファイルから厳格な型定義を強制する。
2. 型定義の明確化: `string | null` のように、`null` が混ざる可能性がある変数を、意識的に型注釈で表現する習慣をチームで共有する。
3. 徐々に拡大: `tsconfig.json` の `include` で範囲を絞りながら、少しずつ `strictNullChecks: true` の対象ファイルを増やしていく。

最後に

TypeScriptの型チェックは、君たちの書くコードに対する「信頼の証」だ。`null` や `undefined` を曖昧なまま放置することは、自分自身や将来の同僚に対する技術的負債の押し付けに過ぎない。

「型エラーがうるさい」と感じるかもしれない。だが、その煩わしさは、本番環境でユーザーが遭遇するかもしれないエラーを、今この瞬間に君が殺してくれている音なんだ。

さあ、エディタを開いて `tsconfig.json` を確認してくれ。そこが、君のプロダクトが「堅牢なソフトウェア」に変わる第一歩だ。

コメント

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