【入門編】 tsconfigのnoUncheckedIndexedAccessオプション – TypeScript実践ガイド

こんにちは!TypeScriptの学習、毎日お疲れ様です。「型があって安全」という触れ込みでTypeScriptを始めたものの、なんだかエラーばかり出てきて、逆に窮屈に感じていませんか?「大丈夫ですよ、みんな最初はそこでつまずきます!」

今日は、そんなTypeScriptの数ある設定の中でも、「知っておくと未来のバグをごっそり防いでくれる隠れた名設定」である、`noUncheckedIndexedAccess` についてお話ししますね。

少し長い名前ですが、怖がる必要は全くありません。身近な例えを交えながら、優しく紐解いていきましょう!

—

1. 配列の「お買い物」と、ちょっと危ない現実

まずは、TypeScriptの基本である「配列(Array)」を想像してみてください。
例えば、スーパーの棚に並んだ3つのおにぎり(インデックス 0, 1, 2)を思い浮かべてみましょう。

const onigiriList: string[] = [“梅”, “鮭”, “明太子”];

あなたは「2番目(インデックスの `1` ですね)の鮭おにぎり取って!」と店員さんにお願いしました。TypeScriptは優しいので、もちろん「それは `string`(文字列)だね」と教えてくれます。

const selected = onigiriList[1]; // 「これは string 型だよ」と教えてくれる

ここまでは平和です。しかし、人間の記憶やプログラムの計算というのは、時々うっかりミスをしますよね。
「うっかり、存在しない 10番目 のおにぎりを取ってきて!」とお願いしてしまったら、どうなるでしょうか?

const ghostOnigiri = onigiriList[10]; // 現実の棚にはそんなものない!

現実の世界なら、店員さんは「お客さん、そんな棚ありませんよ!」とツッコミを入れてくれます。
しかし、標準のTypeScriptは、デフォルトの状態だとこう言います。
「うん、インデックス10だね! きっとそこにあるのも `string`(文字列)だよ!」 と……。

いやいや、ちょっと待って! そんなもの本当は存在しません。実際には `undefined`(何もない空っぽ)が返ってくるはずです。
この「本当はないのに、あると言い張ってしまう嘘」が、現場で恐ろしい「Cannot read properties of undefined (reading ‘length’)」といった、おなじみの真っ赤なエラーを引き起こす原因なんです。

—

2. 救世主:`noUncheckedIndexedAccess` の登場

そこで登場するのが、今回の主役である `tsconfig.json` の設定項目、`noUncheckedIndexedAccess` です。

これを「有効(`true`)」にすると、TypeScriptの厳しさが一段階上がります。
どうなるかというと、配列やオブジェクトからインデックスで値を取り出したとき、TypeScriptがこう叫ぶようになります。

「ちょっと待って! そこ、本当に値があるか分からないよ! `undefined` が混ざるかもしれないから、ちゃんと確認してね!」

言葉だけだと少し厳しく聞こえるかもしれませんが、これはあなたを守るための最強の防護服です。

設定を有効にする方法

プロジェクトの根元にある `tsconfig.json` を開いて、`compilerOptions` の中に一行追加するだけです。

{
“compilerOptions”: {
“target”: “ESNext”,
“module”: “ESNext”,
“strict”: true,

// 👇 ここにこれを追加するだけで、あなたのコードは劇的に安全になります!
“noUncheckedIndexedAccess”: true
}
}

—

3. コードで違いを見てみよう

実際にエディタでどう振る舞いが変わるのか、コード例を見てみましょう。

設定が「オフ(デフォルト)」の世界

const fruits: string[] = [“りんご”, “みかん”, “バナナ”];

// インデックス 5 は存在しないけれど…
const item = fruits[5];

// 型は「string」と言い張られる
// このまま .toUpperCase() なんかを使うと、実行時におアプリがクラッシュします!
console.log(item.toUpperCase()); // 💥 TypeError!

設定が「オン(`noUncheckedIndexedAccess: true`)」の世界

const fruits: string[] = [“りんご”, “みかん”, “バナナ”];

// インデックス 5 を取ろうとすると…
const item = fruits[5];

// 型は 「string | undefined」 になる!
// 「あるかもしれないし、ないかもしれないよ」と正直に教えてくれる

「あれ? 型に `undefined` が混ざると、なんだかコードを書くのが面倒になりそう……?」と思いましたか?
大正解です! 最初は少し面倒に感じるかもしれません。でも、この「面倒くささ」こそが、バグを未然に防ぐ最高の盾なんです。

—

4. 安全に取り扱うための優しい書き方

`undefined` が混ざるようになったら、TypeScriptに怒られないように「ちゃんと確かめてから使う」という優しいコードに書き換えてあげましょう。

実務でよく使われる安全な書き方を2つご紹介しますね。

① 条件分岐でしっかり確認する(ガードする)

一番確実な方法です。「もし中身があったらね」と優しくチェックしてあげます。

const fruits: string[] = [“りんご”, “みかん”, “バナナ”];
const item = fruits[5]; // string | undefined

// 「ちゃんと中身が存在する時だけ処理するよ」と教える
if (item !== undefined) {
// この中では、item は確実に string として扱える!
console.log(item.toUpperCase());
} else {
console.log(“おっと、そんな果物はなかったよ!”);
}

② オプショナルチェイニング(`?.`)を使う

「もし値があったら実行して、なければ何もしない(`undefined`を返す)」という、JavaScriptの便利な機能です。これを使うとスマートに書けます。

const fruits: string[] = [“りんご”, “みかん”, “バナナ”];

// 値があれば大文字にする。なければ undefined をそのまま返すので安全!
const upperItem = fruits[5]?.toUpperCase();

console.log(upperItem); // undefined が出力されるだけで、アプリはクラッシュしない!

—

チーフアーキテクトからのまとめ

初学者のうちは、「エラーを減らしたいのに、設定を変えたら逆にエラーが増えた気がする……」と戸惑ってしまうかもしれません。

でも、安心してください。`noUncheckedIndexedAccess` が教えてくれるエラーは、「あなたのコードの間違いを指摘しているエラー」ではなく、「未来のバグがお客様の画面で爆発するのを、今ここで防いでくれている優しい警告」なんです。

最初は少し窮屈に感じるかもしれませんが、慣れてくると「この設定がないコードベースにはもう戻れない……!」と思うほど、絶大な安心感をあたえてくれます。

ぜひ、あなたのプロジェクトの `tsconfig.json` にも取り入れて、ワンランク上の安全なTypeScriptライフを楽しんでみてくださいね!応援しています!

コメント

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