01.1 JavaScript の何が問題だったか

実行するまで壊れていることが分からない

JavaScript には、書いた時点で間違いを教えてくれる仕組みがありません。次のコードはエラーを出さずに動きます。

// JavaScript
function greet(user) {
	return `Hello, ${user.name}`;
}

console.log(greet({ namae: "Alice" }));   // "Hello, undefined"

namae は name の打ち間違いですが、JavaScript は存在しないプロパティを読んでも undefined を返すだけです。例外も出ず、それらしい文字列が出力されます。この出力を誰かが見つけるまで、間違いは残り続けます。

同じコードに型を付けると、実行する前に止まります。

// TypeScript
type User = { name: string };

function greet(user: User) {
	return `Hello, ${user.name}`;
}

console.log(greet({ namae: "Alice" }));
//                  ~~~~
// error TS2353: Object literal may only specify known properties,
//               and 'namae' does not exist in type 'User'.
//
// 訳: オブジェクト リテラルは既知のプロパティのみ指定できます。
//     'namae' は型 'User' に存在しません。

問題は「間違えること」ではなく「気づけないこと」

どの言語でも打ち間違いはします。JavaScript に固有なのは、間違いが実行時まで表面化せず、しかも実行しても例外にならない場合があることです。

上の3行はテストを書いても見逃す可能性があります。値が「それらしく」出てしまうためです。TypeScript が解決しようとしたのは、この「気づけなさ」です。

01.2 TypeScript は「検査して、型を消す」だけ

tsc がやっていること

TypeScript のコンパイラ tsc がやることは、実質次の2つだけです。

1. 型注釈をもとにコードを検査する
2. 型注釈を取り除いた JavaScript を出力する

出力を見ると分かる

次の .ts をコンパイルすると、

// greet.ts
type User = { name: string; age: number };

export function greet(user: User): string {
	return `Hello, ${user.name}`;
}

出力される .js はこれだけです。

// greet.js — 型に関する記述がすべて消えている
export function greet(user) {
	return `Hello, ${user.name}`;
}

type User の定義も、引数の : User も、戻り値の : string も残りません。型は開発中にだけ存在する情報です。

型エラーがあっても .js は出力される

意外に思われる点ですが、tsc は型エラーを報告しても JavaScript の出力は行います（既定の設定の場合）。型検査と出力は独立した処理だからです。

$ npx tsc greet.ts
greet.ts:7:21 - error TS2353: Object literal may only specify known properties,
                              and 'namae' does not exist in type 'User'.

7 console.log(greet({ namae: "Alice" }));
                      ~~~~

Found 1 error in greet.ts:7

$ ls
greet.js  greet.ts     ← エラーがあっても .js は出力されている

止めたい場合は noEmitOnError を有効にします。設定の詳細は 03. tsconfig で扱います。

動かしてみる

tsx を使うと、コンパイルの手順を意識せずに .ts をそのまま実行できます。

// hello.ts
const name: string = "TypeScript";
console.log(`Hello, ${name}!`);

$ npx tsx hello.ts
Hello, TypeScript!

Node型ストリップ 新しい Node であれば、tsx を使わずそのまま実行することもできます。Node が型注釈を取り除いてから実行するためです。

$ node hello.ts
Hello, TypeScript!

どちらの方法にも制約と使い分けがあります。詳細は 02. 実行環境 で扱います。

01.3 Java・C# のコンパイルとの違い

「コンパイル」という同じ言葉が指すものが違う

Java や C# の経験がある読者ほど、ここで誤解が起きます。どちらもコンパイルと呼びますが、出力されるものも、型情報の行き先も違います。

interface User { name: string }

// 書けない — User は実行時に存在しない
// if (x instanceof User) { ... }
//                ~~~~
// error TS2693: 'User' only refers to a type, but is being used as a value here.
//
// 訳: 'User' は型のみを参照しますが、ここで値として使用されています。

リフレクションに相当するものがない

Java の getClass()、C# の typeof(T) のように実行時に型情報を取り出す仕組みは TypeScript にありません。ジェネリクスの型引数も実行時には消えます（09. ジェネリクス）。

この制約は不便に見えますが、理由は単純です。TypeScript は JavaScript に何も足さないためです。出力が普通の JavaScript である以上、JavaScript にない機能を実行時に持ち込むことはできません。

01.4 型を付ける他の選択肢

JavaScript に型を付ける方法は1つではない

「JavaScript は実行するまで間違いに気づけない」という問題への答えは、TypeScript だけではありません。

JSDoc という選択肢

.js のままコメントで型を書き、tsc に検査だけさせる方法です。ビルドの手順が増えないのが利点です。

// greet.js — 拡張子は .js のまま
/**
 * @param {{ name: string }} user
 * @returns {string}
 */
function greet(user) {
	return `Hello, ${user.name}`;
}

Flow について

かつて TypeScript と競合した型システムに Flow があります。現在の新規プロジェクトで選ぶ理由はほとんどありませんが、古いコードで // @flow というコメントを見かけたら Flow のコードだと判断できれば十分です。