やあ。今日もコードと格闘しているかな？
フロントエンドの世界は移ろいが激しいけれど、TypeScriptという「守護者」を使いこなしている君たちなら、きっと堅牢なアプリケーションを築けているはずだ。
今日は、`tsconfig.json`の中でも、地味だけれど「これがないと始まらない」と言っても過言ではない設定、`alwaysStrict`について深掘りしよう。単に「オンにせよ」と教えられただけでは分からない、ブラウザの裏側で起きていることや、なぜこれが現場の「防波堤」として機能するのかを解説するよ。
—
`alwaysStrict`：なぜ「厳格さ」を強制しなければならないのか
`tsconfig.json`の`compilerOptions`にある`alwaysStrict: true`。これを設定すると、TypeScriptコンパイラは出力されるすべてのJavaScriptファイルの上部に自動的に `’use strict’;` を挿入してくれる。
「今の時代、モジュールシステム（ESM）を使っていればデフォルトで厳格モードになるんじゃないの？」と思うかもしれない。確かにその通りだ。しかし、現場では歴史的経緯のあるコード、あるいはバンドラーの挙動、特定の環境下での実行など、予期せぬ「落とし穴」が常に待ち受けている。
`alwaysStrict`は、その落とし穴をコンパイルタイムで確実に埋めるための、我々エンジニアの「良心」なんだ。
—
ブラウザの裏側で何が起きているのか
そもそも、`’use strict’;`（厳格モード）が何をしているか、改めて整理しよう。これは、JavaScriptの「甘ったれた仕様」をいくつか封印し、エラーをより早期に、明確に発見するためのものだ。
1. 暗黙のグローバル変数の禁止: 宣言していない変数に値を代入しようとすると、`ReferenceError`を投げる。
2. `this`の挙動の適正化: 通常の関数呼び出しでの`this`は`undefined`になる（非厳格モードでは`window`や`global`を指してしまう！）。
3. 削除できないプロパティの削除禁止: `delete`演算子で消せないものを消そうとするとエラーになる。
ブラウザのエンジン（V8など）は、`’use strict’;`を検知すると、最適化のパスを切り替えることがある。例えば、曖昧な`this`の参照を解決するためのオーバーヘッドを削減したり、静的解析が容易になるため、JITコンパイラがより効率的なマシンコードを生成しやすくなる。
つまり、`alwaysStrict`を有効にするということは、コードの安全性を高めるだけでなく、実行時のパフォーマンス向上にも寄与するというわけだ。
—
実践：コピペで使える設定ファイル
現場で迷わないための、標準的かつ堅実な`tsconfig.json`の該当箇所はこれだ。
{
“compilerOptions”: {
/
alwaysStrict: true は、すべてのモジュールを厳格モードで解析・出力させる。
中規模以上のプロジェクトでは「必須」の設定だ。
/
“alwaysStrict”: true,
/
関連する設定として “strict”: true を推奨する。
これは alwaysStrict を含む複数の厳格化オプションを一度に有効にする。
/
“strict”: true,
/ ターゲットは適宜調整してほしいが、ES2020以降ならモダンな機能も使いやすい /
“target”: “ES2020”,
“module”: “ESNext”
}
}
—
現場で遭遇する「落とし穴」と対策
ある日、君のチームの後輩が「なぜか`this`が`undefined`になって動かない！」とパニックになるかもしれない。それは、`alwaysStrict`のおかげで、彼が書いた「あやふやなコード」が表面化しただけなんだ。
例えば、以下のようなコードだ。
// 厳格モードではこの関数内の this は undefined になる
function User(name: string) {
this.name = name; // エラー: ‘this’ は ‘any’ 型である可能性があります。
}
// 修正案: クラス構文を使うのが現代のベストプラクティス
class User {
name: string;
constructor(name: string) {
this.name = name; // これなら安全かつ意図通りに動作する
}
}
もし`alwaysStrict`がなければ、このコードは非厳格モードで動作し、`this`がグローバルオブジェクトを書き換えてしまう……なんていう、デバッグ地獄の入り口を歩くことになる。
—
シニアからのアドバイス
`alwaysStrict`や`strict`モードをオンにすると、既存プロジェクトでは大量の型エラーが噴出するかもしれない。最初は心が折れそうになるだろう。
だが、思い出してほしい。そのエラーは、君がこれまで見過ごしてきた「バグの芽」そのものだ。
一度にすべてを直す必要はない。`tsconfig.json`を少しずつ厳しくし、型定義を一つずつ丁寧に当てていく。その泥臭い作業こそが、数ヶ月後の君を「深夜のホットフィックス」という名の悪夢から救い出してくれるはずだ。
フロントエンドのアーキテクトとして、まずはこの小さな「厳格さ」のスイッチを入れるところから始めてみてくれ。それが、プロのエンジニアとしての第一歩だ。
何か詰まったら、いつでも聞きに来るといい。一緒にコードの迷宮を解き明かそう。
コメント