TypeScriptの勝利。それが実際に私たちにもたらしたもの。

もはやTypeScriptを使うべきかどうかで議論する人はいない。新規プロジェクトではデフォルトで使用される。論争は終わったのだ。

真の価値は、単にタイポ（打ち間違い）を見つけることだけではない。それよりもずっと大きなものだ。

関数のシグネチャはドキュメントとして機能する。それが古くなることはない。コードが変更されれば、コンパイラがビルドを失敗させる。

この関数を見てほしい：

function scheduleReminder(
  userId: string,
  at: Date,
  channel: "email" | "push" | "sms",
): Promise<ReminderId>;

これをどう呼び出すべきか、正確にわかる。何が必要で、何を返すのかもわかる。channel は3つの特定の文字列のいずれかでなければならないこともわかる。

後で "slack" オプションを追加した場合、コンパイラがコードのあらゆる部分を更新するように強制する。コメントであれば、ただ形骸化し、嘘をつくことになるだろう。

型のないコードでは、フィールド名を変更するのは恐ろしい作業だ。文字列を検索して、あとは祈るしかない。TypeScriptなら、型を変更するだけでいい。コンパイラが壊れた箇所の「ToDoリスト」を提示してくれる。リファクタリングが安全になるのだ。

型はAIの助けにもなる。

AIモデルはJavaScriptではコードの形状を推測する。しかしTypeScriptでは、型が仕様となる。AIは何が許可されているかを理解できる。ミスは本番環境のクラッシュではなく、エラーとして現れる。

型はガードレールとして機能する。一行ずつ手動でチェックする代わりに、自信を持ってAIが生成したコードを利用できるようになる。

以下のルールに従って、より良い型を書こう：

• 多くのBooleanを使う代わりにUnion型を使う。「loading」 | 「error」 | 「ready」のようなステータスは、3つの個別のフラグよりも優れている。 • ドメイン型に名前をつける。意図を示すために type Cents = number のように使う。 • any を避ける。代わりに unknown を使い、型を絞り込む（narrowing）。 • 型推論を活用する。関数のシグネチャのような境界部分には型注釈を付けるが、それ以外は推論に任せる。

TypeScriptはコードベースを「強制された契約」の集合へと変えた。これらの契約によって、恐れを知らないリファクタリングと、信頼できるAIによる支援が可能になる。

私たちはバグを防ぐために型を使い始めた。そして、型が他のあらゆるものの基盤であるからこそ、使い続けているのだ。

Source: https://dev.to/parsajiravand/typescript-won-heres-what-that-actually-bought-us-53lo