【第15回】どこまで厳しく見張らせるか決める｜tsconfig と strict（嫁子が教えるTS講座）

今回のゴール

• TypeScriptを実際にJavaScriptへ変換して動かせる
• tsconfig.json の中で見るべき項目が分かる
• strict を最初から入れる理由が説明できる

前回（ジェネリクス）まで読み方の話が続きました。今回は手を動かして、次回の書き換えの準備をします。全体の流れは講座の目次へ。

嫁子: 設定ファイルの回って退屈になりがちなんだけど、今日は1つだけ持ち帰ってほしいことがあるの。

strict は最初からオンにする。これだけ。

理由は途中で説明するけど、先に結論を言っておくね。後から厳しくするのは、最初から厳しくするより何倍もつらいからだよ。

① 準備する

第2回で作った作業フォルダで進めます。ターミナルで順に打ってください。

npm init -y
npm install --save-dev typescript
npx tsc --init

上から「このフォルダをNode.jsの管理下に置く」「TypeScriptをこのフォルダに入れる」「設定ファイルを作る」です。

3つ目が終わると tsconfig.json ができます。

Windowsでうまくいかないとき：PowerShellの設定で npx が止まることがあります。その場合は npx.cmd と打つと通ります（中身は同じものです）。

嫁子: --save-dev は「開発中だけ使うもの」という印だよ。

TypeScriptは変換するときにしか要らないからね。できあがったJavaScriptを動かすときには不要なの。そういう道具はここに入れておく、という約束事だと思っておいて。

② 変換して動かす

app.ts というファイルを作って、中身をこう書きます。

const price: number = 1200;
const count: number = 3;
console.log(price * count);

そして変換します。

npx tsc

同じ場所に app.js ができます。中を見ると、型注釈だけが消えたJavaScriptになっているはずです。第11回で説明した「型は実行時に消える」がこれです。

動かすのは、できあがった .js のほうです。

node app.js

毎回打つのが面倒なら、監視モードにしておくと保存のたびに変換されます。

npx tsc --watch

③ tsconfig.json で見るところ

生成されたファイルには項目がたくさん並んでいますが、最初に見るのは4つだけで足ります。中身はTypeScriptのバージョンによって初期値が違うので、値そのものより「どの項目か」を覚えてください。

outDir を指定しておくと、.ts と .js が同じ場所に散らばらずに済みます。

{
  "compilerOptions": {
    "strict": true,
    "target": "ES2020",
    "outDir": "dist"
  }
}

嫁子: 他の項目は、必要になったときにAIに聞けばいいよ。

「この設定は何をしてるの？」と貼れば説明してくれるからね。全部を理解してから始める必要はないの。むしろそれをやろうとすると、ここで止まる。

④ strict は何を厳しくするのか

strict は1つの設定ではなく、複数のチェックをまとめてオンにするスイッチです。代表的なのはこの2つです。

型を書き忘れた引数を許さない

function total(price, count) {   // strict では エラー
  return price * count;
}

型を書いていない引数は、暗黙のうちに any になります。第12回で見た通り、any はチェックを止めます。strict は、それが黙って起きるのを防ぎます。

「無いかもしれない」を無視させない

const el = document.getElementById("title");
el.textContent = "こんにちは";
// strict では エラー: 'el' は 'null' の可能性があります

第9回で「null が出たら id が合っていない」と書きました。strict をオンにしておくと、その事故が起きうる場所を、書いている時点で全部指摘してくれます。

書き方はこうなります。

const el = document.getElementById("title");
if (el === null) {
  throw new Error("要素が見つかりません");
}
el.textContent = "こんにちは";

行数は増えますが、増えたぶんはそのまま「起きなくなった事故」です。

⑤ なぜ最初から入れるのか

途中から strict をオンにすると、それまでに書いた全ファイルのエラーが一度に出ます。数百件になることも珍しくありません。

最初から入れておけば、書いたそばから1件ずつ潰せます。同じ総量の作業でも、1件ずつなら止まらずに進めます。

嫁子: これ、片付けと同じだよ。毎日やれば5分、半年ためたら週末がまるごと消えるでしょ。

しかもAIに書かせると、コードが増える速度は人間の比じゃないからね。ためこむ速度も速いってこと。だから最初なの。

⑥ エラーが大量に出たときの進め方

strict をオンにした直後や、既存のコードを移したときは、エラーが並びます。ここでの動き方が第3部の実用的なところです。

1件ずつAIに渡すより、まとめて渡すほうが速いです。

npx tsc --noEmit

--noEmit は「変換せず、チェックだけする」という指定です。出てきたエラー一覧をそのまま貼って、こう頼みます。

このエラーを、any を使わずに直してください。1件ずつ、何を直したかも教えてください。

any を使わずに、という条件は必ず付けてください。付けないと、AIは any で黙らせる直し方を選ぶことがあります。

嫁子: エラーが消えたことと、問題が消えたことは違うの。前回も言ったけど、ここが第3部でいちばん大事なところだと思ってる。

AIは「エラーを消して」と言われたら消すよ。どう消すかを決めるのは、頼む側の仕事なんだよね。

つまずきポイント

tsc は .ts を書き換えません。別に .js を作ります。編集するのは常に .ts のほうで、.js は変換のたびに上書きされます。

HTMLから読み込むのも .js です。<script src="app.js"> のままで構いません。ブラウザは .ts を実行できません。

設定を変えたら、変換し直してください。--watch を使っていない場合は、npx tsc をもう一度打ちます。

今回のまとめ

• npm install --save-dev typescript → npx tsc --init → npx tsc で変換できる
• 動かすのは変換後の .js。--watch で保存のたびに自動変換
• tsconfig で最初に見るのは strict / target / outDir / include
• strict は最初からオンにする。後から入れると数百件のエラーが一度に出る
• エラーは npx tsc --noEmit でまとめて出し、「any を使わずに直して」とAIに渡す

次にやること

次回は第2部の買い物メモをTypeScriptに書き換えるです。第3部の締めくくりで、ここまでの型を実際のコードに当てていきます。strict をオンにしたときに出るエラーを、1つずつ潰していく回になります。

今回の宿題：上の app.ts を作って npx tsc を通し、できあがった app.js を開いてみてください。型注釈だけが消えているのを目で確認するのが目的です。

嫁子: 中身を見ると、拍子抜けするくらい普通のJavaScriptだと思うよ。

でもそれが分かると、TypeScriptは別世界の言語じゃないと腹に落ちるからね。ここは1回見ておく価値があるよ。