TypeScriptを使ってECMAScript 2015時代のコードを書く 3

第一回は、「なぜTypeScriptか？」という話を書きました。前回はTypeScriptで開発する際の環境についてがテーマでした。今回は、最後の締めくくりとしてECMAScript 2015において積極的に利用するべき構文を紹介していきます。

まず、TypeScriptの近況をお伝えしておきます。TypeScriptの現在のバージョンは1.7.5で、この後もまだまだアップデート予定は詰まっています。アップデートの予定はたくさんありますが、これは必ずしも機能が十分に揃っていないということを意味しません。

第一回で触れたとおり、TypeScriptはECMAScript 2015のsuperset+型のための構文が導入された言語です。TypeScriptの今後のアップデートはTypeScript自体の使い勝手や、型の柔軟性を改善するためのものが大部分。その証左として、1.5.3より後の1.6.2、1.7.5のアップデートではECMAScript 2015の構文の追加はGeneratorsくらいのものです。つまり、TypeScriptはすでにECMAScript 2015による記述を行うためには十分成熟している、といえます。

次に挙げる機能を使う場合、多くのブラウザで動作させるために何らかの後処理が必要になります。

• Modules
  • ECMAScript 2015としてのmoduleの仕様は決まりましたが、ブラウザ上で動かせる状態にはありません。そのため、require.jsやbrowserify、SystemJSなどのツールが必要。
  • なお、Node.js上で動作させる場合はCommonJSスタイルのJavaScriptとして出力できるためTypeScriptコンパイラによる変換だけで利用可能。
• Generators
  • --target es6でのみ利用可である（es5で動く形式に変換できない）ため、利用したい場合はbabelによる変換が必要。

また、仕組み上es5で動く形に変換ができない（つまり、全くの新機能である）ものもいくつかあります。ブラウザなどの進歩を待ちましょう。

本稿では、すべてのサンプルコードは現代的に、つまりECMAScript 2015的に書くことにします。古くからのJavaScriptユーザとしては見慣れないかもしれない、そして別の言語に慣れている人には、比較的読みやすい記法でしょう。

これから紹介するTypeScript独自の記法ではないものは正式にJavaScriptの仕様になったものであるため、今後数年以内に徐々にすべてのJavaScriptコードが本稿で紹介されるような記法へと移行されていく…といいなぁ。

また、本稿に出てくるサンプルコードはTypeScript playgroundですぐに試せるリンクをなるべく添えています。Playground上で、変数名などにマウスカーソルをホバーさせるとどういう型として解釈されているか確認できるのでいろいろ試してみてください。Playgroundはmodule周りのサポートがすっぽり抜け落ちているので、その辺りは割愛しています。前回の記事を参考に、自分で環境を整え、試してみてください。

TypeScript独自の構文

まずは、TypeScript独自の構文について述べておきます。独自の構文といっても、型に関する部分についてなのでプログラムの動作には影響しません。プログラムの堅牢さ、分かりやすさ、保守しやすさによい影響があります。

詳しく知りたい場合は、筆者の書いた別の解説やTypeScriptの更新差分解説を参照してください。

型注釈の基本

TypeScript最大の特徴として、型の存在とそれを利用した静的なチェックがあります。

JavaScriptにももちろん型は存在しています。string, number, Date, RegExpなどなど多岐に渡りますがJavaScriptでは変数と型を結びつけるということをしませんでした。

TypeScriptでは変数に型を明示的に指定（注釈を与える）ことにより、静的なチェックやIDEによる支援を受けることができます。

変数や引数について型の指定ができる箇所は多くありますが、基本的に次の箇所だけマークしておけば多くの局面に対応できます。

• 初期化なしの変数宣言
• 関数の仮引数
• 関数の戻り値の型
• 型パラメータ

TypeScriptでは、変数や仮引数などの後に: 型名という形式で記述します。number, boolean, string, void, anyなど、組み込みの型と、DateやRegExpなど、見知ったJavaScriptのオブジェクトも存在しています。

"use strict";

// 関数の仮引数と戻り値の型
function concat(a: string, b: string): string {
    return a + b;
}

// 変数の型
let obj1: RegExp;
// 初期化子がある場合、わざわざ型注釈を明記しなくとも自動的に推論される
let obj2 = /^Hi!$/;

let array1: Array;
// array1 と全く同じ意味合い
let array2: boolean[];

Playgroundで試す

簡単ですね。型パラメータの考え方は、JavaやC#を知っている人であれば、馴染みのある記法でしょう。TypeScriptは配列だけは特別扱いをしており、Arrayなどの記法の他に、boolean[]という記法をも許しています。これも、JavaやC#を知る人であれば、見たことがある記法かもしれません。TypeScriptでは、配列についてはboolean[]の記法を使うほうが一般的です。

Interfaces

インタフェースは、あるオブジェクトについての性質を記述し、それに名前をつけることができます。JavaやC#ではあるクラスに特定の実装を強制するものとして使いますが、TypeScriptではその範囲にとどまりません。

クラス化するほどでもない、サーバから受け取るデータについて名前をちょいちょいと与える場合などに使われる場合が多いです。

"use strict";

interface Sample {
    str: string;
    func: (n: string) => number;
    methodA(): void;
}

let obj: Sample;
obj.str;
obj.func("test");
obj.methodA();

Playgroundで試す

ECMAScript 2015

さて、それではECMAScript 2015の構文の説明に入っていきます。筆者が育てている4つの個人リポジトリのソースコードを見て、実際に使っているもののみを抜粋してきました。

つまり、ここで紹介している構文は使い勝手がよく、ECMAScript 2015以前よりも改善されている構文である！といえます。

use strict

まずは、 “use strict”; について紹介しておきます。これはECMAScript 5のときからあるディレクティブです。

"use strict";

// getterのみあり setterなし
let obj = {
    get str() {
        return "Hi!";
    }
};

// エラーにしてくれる！
// Uncaught TypeError: Cannot set property str of # which has only a getter
// "use strict"; がないと、単に無視されるので値がセットされない謎のバグになり苦しみのたうつ
obj.str = "setterは存在していない";

Playgroundで試す

多くの効能があるため、ここでは詳細には解説しません。ここで解説した理由は、ECMAScript 2015の仕様上、後述のクラスやモジュールの内部は暗黙的にstrict modeになるためです。TypeScriptで書いたコードをコンパイルするとクラスやモジュールの構文も変換されてしまい、暗黙的にstrict modeではなくなってしまいます。

そのため、後々ECMAScript 2015が無変換で動く時代になった時に困らぬよう、今のうちからすべてのファイルの先頭に"use strict";を書いておき、挙動を揃えておきます。これはトイレに行った後に手を洗うというレベルのエチケットなので、tslintなどを活用して忘れないように気をつけましょう。

let, const

let, constを紹介します。JavaScriptではvarというキーワードを使って変数定義をしていました。let, constではvarに対して次の違いがあります。

• ブロックスコープである
• 同じ変数名を複数回定義しようとするとエラーになる
• 変数の巻き上げは行われるが宣言前にアクセスするとエラーになる

constの場合、さらに追加があります。

• 宣言時に初期化必須
• 値の置き換え不可

便利ですね。varの不思議な挙動について理解しておかねばならない時代も過去のものとなりそうです。多くの場合で単純にvarをletに置き換えできるし、そうしたほうがよいでしょう。varをletに置き換えて動かなくなるようなコードは、JavaScriptの不快な仕様を利用した悪いコードだと考え、リファクタリングするべきです。

"use strict";

let objA = "Aだよ！";
// ブロックスコープだ！ varはブロックスコープではない
{
    let objA = "Aだけど2番目だよ！";
    // Aだけど2番目だよ！ と表示される
    console.log(objA);
}
// Aだよ！ と表示される
console.log(objA);

// 2重に宣言してもエラーにならない
var objB: any;
var objB: any;

// 2重に宣言するとちゃんとエラーになる（TypeScript上でもプログラム実行時でも）
let objC: any;
let objC: any;

// 定数として宣言すると値の書き換えはエラーになる（TypeScript上でもプログラム実行時でも）
const objD = "Hi!";
objD = "Bye!";

// ちなみに値のさらに中身を書き換えるのは問題ない
const objE = {
    str: "Hi!"
};
objE.str = "Bye!";
// 対策（実行時エラーになる）
const objF = Object.freeze({
    str: "Hi!"
});
objF.str = "Bye!";

Playgroundで試す

なお、TypeScriptで--target es5などでコンパイルした時はletがvarに変換されるため、実行時エラーは発生しなくなってしまいます。実用上はコンパイル時にそれと分かればとりあえずは問題ないでしょう。

Classes

オブジェクト指向な言語であればだいたい存在するクラスです。JavaScriptではECMAScript 2015から導入されました。ECMAScript 5までは、prototypeという仕組みを使ってオブジェクト指向なコードを書いていました。

prototypeにも良いところがあり、悪いモノでもないのですが、広く知られているという分かりやすさ、関連する記述がひとところにまとまっているという利点を考えると、やはりclassが使えるというのはありがたいものです。

今後、prototypeの出番は大きく減るでしょう。とはいえ、classの裏側はprototypeであるため、今まで使えたハックも利用可能ではあります。

"use strict";

class Sample {
    name: string;

    constructor(name: string, public extention = "!") {
        this.name = name;
    }

    hi(): string {
        return `Hi, ${this.name}${this.extention}`;
    }
}

let obj = new Sample("TypeScript");
// Hi, TypeScript! と表示される
console.log(obj.hi());

Playgroundで試す

JavaやC#を見慣れているユーザであれば、大変親しみやすいコードになったと思います。ぜひ、PlaygroundでどういうES5なコードに変換されるかを確認してみてください。これを手書きで書くのは、チーム内の人数が多くなれば多くなるほど辛く感じるでしょう。

また、クラスが使えるようになりましたが、だからといってなんでもかんでもクラスにしなければならないわけではありません。今までどおり、関数や普通のオブジェクトを使うのが適していると思った場合はどんどん使って構いません。無理にクラスを使おうとするほうが、意図のわかりづらい、よくないコードになってしまうでしょう。

TypeScriptのみの独自仕様として、constructorでpublic extention = "!"のように、アクセス修飾子付きで仮引数を宣言すると、自動的に自分のプロパティとしてセットされます。ECMAScript 2015の仕様に準拠したコードを書きたい場合は、nameプロパティのように、フィールドの宣言をしてからthis.name = name;のように自分で代入しましょう。

気になる場合は、tscでのコンパイル時に--target es6を指定してコンパイルし、どのようなpure ECMAScript 2015コードが生成されるかをチェックしてみるとよいでしょう。

Modules

モジュールです。ECMAScript 2015では、ついにモジュールという概念が、JavaScriptの仕様として盛り込まれました。今までのJavaScriptにはモジュールの仕様が正式にはなく、AMDやCommonJSなど、それを埋めるための（ECMAScriptではない）仕様が複数考えだされ、実装されてきました。Node.jsではCommonJSのモジュールに仕様に近いものが採用されています。

ECMAScript 2015でのモジュールの仕様は、ざっくりいうと 1ファイル=1モジュール という仕様です。1ファイル毎に名前空間が分割されていて、どの識別子を外部に公開するかを選択していきます。

モジュールの仕様は、静的に（つまり実行することなく）ソースコード間の依存関係が解決できるようになっています。そのため、今までのJavaScriptのコードとはかけ離れた、全く新しい構文をもっています。

コード例を見ていきましょう。utilA.ts, utilB.ts, main.ts という3つのコードを利用します。3ファイルあるので、モジュールが3つあることになります。

"use strict";

export default function() {
    return "Hi! from utilA";
}

"use strict";

export function hi() {
    return "Hi! from utilB";
}

"use strict";
// es6 moduleを使うと自動的に use strict した事になる。
// しかし、TypeScriptでコンパイルするとそうではなくなってしまうので明示的に指定しておく。

import utilA from "./utilA";
import {hi} from "./utilB";
import * as utilB from "./utilB";

// Hi! from utilA と表示される
console.log(utilA());
// Hi! from utilB と表示される
console.log(hi());
// Hi! from utilB と表示される
console.log(utilB.hi());

残念ながら、Playgroundで試すことができないので、お手元に環境を作って試してみてください。

exportして、importするだけの仕様ではありますが、慣れるまでは正しい記法がわかりづらく戸惑いを覚えるでしょう。TypeScriptの利点として、動作しない書き方をした場合きっちりコンパイルエラーにしてくれるので試行錯誤する手間が省けます。

Arrow functions

Arrow functions（アロー関数）です。ECMAScript 5までのJavaScriptの関数は、thisの値が他言語ユーザの期待とだいぶかけ離れた動作をしていて辛かったです。アロー関数では期待する挙動と実際の挙動の齟齬がだいぶ軽減されています。

"use strict";

// 引数なしの場合 括弧は必要
let funcA = () => {
    console.log("Hi!");
};
// Hi! と表示される
funcA();

// 引数1個の場合、括弧をつけることもできる
let funcB = (name: string) => {
    console.log(`Hi! ${name}`);
};
// Hi! TypeScript と表示される
funcB("TypeScript");

// 引数が1個の場合、括弧を省略して仮引数名のみを書くことができる
// ただし、括弧を省略する場合仮引数の型を指定することはできない
// このため、ここではfuncC変数に型を指定している
let funcC: (name: string) => void = name => {
    console.log(`Hi! ${name}`);
};
// Hi! TypeScript と表示される
funcC("TypeScript");
// 既に型がついている場合そのまま省略できる
funcC = name => {
    console.log(`Hi! ${name}`);
};
// Hi! TypeScript と表示される
funcC("TypeScript");

let funcD = (name: string, ...rest: string[]) => {
    console.log(`Hi! ${name} and ${rest.join(", ")}`);
};
// Hi! TypeScript and ECMAScript 2015, ECMAScript 2016 と表示される
funcD("TypeScript", "ECMAScript 2015", "ECMAScript 2016");

Playgroundで試す

この使い方では、EMCAScript 5の関数と大差ありませんね。タイプする文字数が減って嬉しいですが、まあ、その程度です。名前付きアロー関数は作ることができませんので、素直に変数に代入しましょう。

次の例を見てみましょう。

"use strict";

class Sample {
    constructor(public name: string) {
    }

    toString(): string {
        return `${this.name}!`;
    }

    method() {
        // ここはmethodのトップレベルです

        let funcA = () => {
            // arguments にアクセスできない
            // thisの値はmethodのトップレベルと変わらない
            console.log(`Hi, ${this}`);
        };
        let funcB = function() {
            // arguments にアクセスできる
            // thisの値は undefined
            console.log(`Hi, ${this}`);
        };

        // Hi, TypeScript! と表示される
        funcA();
        // Hi, undefined と表示される
        funcB();
    }
}

let obj = new Sample("TypeScript");
obj.method();

Playgroundで試す

アロー関数の特徴が顕著に出ていますね。

理由が明確に説明できない限り、今後はfunctionと記述する関数ではなく、アロー関数を使うべきでしょう。具体的に、今までのfunctionを使うのは名前付き関数を作りたい場合や、thisの値を変更するタイプのAPIをもつライブラリを使う場合などです。

Default parameters, Rest parameters, Spread operators

Default parameters（デフォルト値付き引数）、rest parameters（可変長引数）、Spread operators（展開演算子）について取り上げます。これらもECMAScript 2015からの導入になりますが、特にお世話になるのはデフォルト値付き引数でしょう。

"use strict";

// デフォルト値付き引数
// 当てはまる引数が渡されない場合、指定された値がデフォルト値として利用される
function hi(name = "TypeScript") {
    return `Hi! ${name}`;
}
// Hi! TypeScript と表示される
console.log(hi());
// Hi! ECMAScript 2015 と表示される
console.log(hi("ECMAScript 2015"));

// 可変長引数
function bye(...names: string[]) {
    if (names.length === 0) {
        return `Bye, JavaScript`;
    }
    return `Bye, ${names.join(", ")}`;
}
// Bye, JavaScript と表示される
console.log(bye());
// Bye, JavaScript, ECMAScript 3 と表示される
console.log(bye("JavaScript", "ECMAScript 3"));

function goodOldDays() {
    return ["JavaScript", "ECMAScript 3", "ECMAScript 5"];
}

let array = goodOldDays();
// spread（展開）される
// Bye, JavaScript, ECMAScript 3, ECMAScript 5 と表示される
console.log(bye(...array));
// 同上
console.log(bye(array[0], array[1], array[2]));

Playgroundで試す

ECMAScript 5までは、p = p || "TypeScript";のような、JavaScriptユーザ以外にはわかりにくいイディオムを取る必要がありましたがだいぶわかりやすくなりましたね。

Template string

Template stringは文字列の生成が今までより簡単にできるようになりました。これにより、文字列を結合してメッセージなどを生成するのが格段に読みやすくなります。Gruntfile.jsやgulpfile.jsでできると、設定ファイルも大変見やすく保守も簡単になります。

"use strict";

let name = "TypeScript";
// Hi! TypeScript と表示される
console.log(`Hi! ${name}`);

name = "ECMAScript 2015"
// Hi! ECMAScript 2015 と表示される
console.log(`Hi! ${name}`);

// Hi! ECMAScript 2015 と表示される
console.log("Hi! " + name);

Playgroundで試す

まさにテンプレートですね。

Tagged template stringという機能もあるのですが、あまり有効な使いみちがないのと、活用した有名なライブラリなども登場してきていないので入門レベルでは気にする必要はないでしょう。

Promises

ECMAScript 2015から、非同期処理における標準のAPIが定義されました。それがPromiseです。Promiseは「約束する」の名の示すとおり、将来的に処理結果を返すことを約束し、その予約表を先に払い出すイメージです。Promiseの結果は成功か失敗の2状態で表されます。

"use strict";

let p1 = Promise.resolve(true);
p1.then(value => {
    // true と表示される
    console.log(value);
});

let p2 = Promise.reject("何かのエラー！");
p2.then(value => {
    // rejectの場合はここに到達しない
    console.log(value);
}, err => {
    // 何かのエラー！ と表示される
    console.log(err);
});

let p3 = Promise.reject("何かのエラー！");
p3.catch(err => {
    // 何かのエラー！ と表示される
    console.log(err);
});

let p4 = new Promise((resolve, reject) => {
    let xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
        if (xhr.readyState == 4) {
            if (xhr.status == 200) {
                resolve(xhr.responseText);
            } else {
                reject(xhr);
            }
        }
    }
    xhr.open("GET", "http://www.typescriptlang.org/");
    xhr.send();
});
p4
    .then(text => {
        // 通信が成功していたらHTMLがどばー！と表示される
        console.log(text);
    })
    .catch((xhr: XMLHttpRequest) => {
        // 通信に失敗していたらステータスコードが表示される
        console.log(xhr.status);
    });

Playgroundで試す

Playgroundは--target es5で動作しているため、Promiseの型定義が存在していません。コンパイルエラーが出ていてもRunすることはできますが、できれば手元で試してみるのがよいでしょう。

Promiseは今後さまざまな標準APIの一部として使われることになります。ブラウザ上で動くコードを書いている場合でも、ServiceWorkerやfetch APIなどを使うようになると、まず間違いなく触らなければいけなくなるため、今のうちに確実にマスターしておくことをお勧めします。azuさんのPromise本が大変わかりやすいので熟読すると得るものが大きいと思います。

まとめ

いかがでしょうか。わかりやすく使いやすい変更が多いので、今すぐにでも使い始められると思います。まずは、既存コードなしの100% TypeScriptなコードから書き始め、徐々に適用範囲を広げていってみてください。

CoffeeScriptやECMAScript 5なコードからは遅かれ早かれ移行しなければならないと思いますので、本記事を参考に徐々に実践を始めてみてください！それでは良いTypeScript & ECMAScript 2015ライフを！

前回はなぜTypeScriptか？という話を書きました。今回はTypeScriptを使うとして、どういう環境を作れば気持ちよく開発できるかについて解説します。

本稿に出てくるサンプルをまとめたリポジトリを随時メンテしております。時期によっては、本記事の内容に沿わない（より磨かれた）状態になっているかもしれません。

TypeScriptの開発環境が指すものは2つあります。IDEやエディタといった、本当に開発を行うための環境と、初期設定を行ったりリリースビルドを作ったりするためのタスクランナーの二種類です。

本記事ではお勧めの構成として、Visual Studio Code+grunt+dtsmを用いていきます。別構成として、Atomとgulp、tsdについても言及します。いずれの構成でも、Mac OS X、Windows、Linuxといった主要なプラットフォームで同じように動かすことができます。

TypeScriptのインストール

Node.js+npmはすでに導入してある前提で進めます。$ npm install -g typescriptか、それで失敗する環境の場合は$ sudo npm install -g typescriptを行ってください。現時点（2015年10月9日）では、TypeScript 1.6.2がインストールされます。TypeScriptコンパイラ（tscコマンド）のバージョンを確認するには、$ tsc -vを実行します。

tsconfig.json

tsconfig.jsonはTypeScript 1.5.3から登場した要素です。TypeScriptコードをコンパイルする際に、コンパイルオプションとコンパイル対象のtsコードの指定をひとまとめにした設定ファイルです。

今までTypeScriptのコードをJavaScriptにコンパイルするには、tscコマンドにコンパイルオプションや.tsファイルのパスを与えてコンパイルしていました。この方法の問題点は、どういうオプションを渡せばプロジェクトを正しくコンパイルすることができるかわからないということです。また、ファイル同士の依存関係の記述方法も問題でした。reference commentと呼ばれる、TypeScriptコード同士の依存関係をコード中に書く方式が一番最初にありました。これだと依存関係をいちいち記述するのが大変面倒くさく、コンパイル時のエントリーポイントとなるコードを間違えると生成されるコードが変わり、その影響で依存順次第で実行時エラーになる…というパターンもありました。

後述するgruntやgulpなどのタスクランナーを使えば、プロジェクトメンバーやコントリビュータとの手法の共有はできるようになります。依存関係についても毎回同じ方法でコンパイルするようになるため、コンパイル開始のエントリポイントとなる1つのファイルからtree状に依存関係を記述していく方法で楽をすることができるようになりました。しかし、IDEやエディタからはGruntfile.jsやgulpfile.jsの設定値は活用することができないため、入力補完やエラー報告の正確さに不満がありました。

これら、コンパイル方法の指定・TypeScriptコード同士の依存関係を解決できるのが、ここで紹介するtsconfig.jsonです。tsconfig.jsonはTypeScriptコンパイラ、人間、エディタの3者が理解することができる、便利なコンパイル方法の記述手段なのです。

Microsoft先生は最近OSSに対する貢献をどんどん強化してきていますが、まだNode.js+npmやエディタ周りの文化に対する理解が薄いです。そのためtsconfig.jsonについて、めちゃめちゃ使いにくい仕様が生まれています。たとえば、TypeScript 1.5.3ではfilesプロパティにコンパイル対象とするファイルの一覧を1つ1つ書かねばならず、大変面倒くさいです。TypeScript 1.6.0-betaではexcludeプロパティに除外するファイルやフォルダを指定できますが、filesプロパティとの併用はできませんし一部除外解除の設定もできません。basarat氏がatom-typescriptで実装している、filesGlobsプロパティのように、ワイルドカードや除外ルールの組み合わせで順番や対象をコントロールできる方式のほうが優れていると思うのですけどね。

とはいえ、tsconfig.jsonを使いこなすと便利です。今後はtsconfig.jsonがあるとTypeScriptでコードを書くにあたりいろいろな恩恵が得られると思いますので、本連載ではtsconfig.jsonを中心とした環境づくりを紹介していきます。

では、実際にtsconfig.jsonを使ってみましょう。tsconfig.jsonは特別な理由がない限り、プロジェクトルートに1つ置いて使います。TypeScript 1.6.0-beta以降では、--initオプションが使えるため、tsc --initを実行するとリスト1が得られます。

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es3",
        "noImplicitAny": false,
        "outDir": "built",
        "rootDir": ".",
        "sourceMap": false
    },
    "exclude": [
        "node_modules"
    ]
}

特にこだわりがなければ、このまま使いはじめてもよいでしょう。しかし、excludeプロパティだけでの運用は細やかなコントロールができないため難しいでしょう。

本連載では、リスト2の構成を使います。filesGlobプロパティはtscコマンドやVSCがサポートしているプロパティではありません。atom-typescriptやgrunt-tsconfig-update、gulp-tsconfig-updateによるfilesプロパティへの展開などのフローを組み合わせていくことでフォローしていきます。リスト2の設定であれば、libディレクトリ配下に置いたコード、testディレクトリ配下に置いたコード、typings配下に置いた型定義ファイルがコンパイル時に自動的に処理されるようになるでしょう。

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "noImplicitAny": true,
        "experimentalDecorators": false,
        "sourceMap": true,
        "declaration": false,
        "noEmitOnError": true
    },
    "filesGlob": [
        "./lib/**/*.ts",
        "./lib/**/*.tsx",
        "!./lib/**/*.d.ts",
        "./test/**/*.ts",
        "./test/**/*.tsx",
        "!./test/**/*.d.ts",
        "./typings/**/*.ts",
        "./node_modules/typescript/lib/lib.es6.d.ts"
    ],
    "files": [
    ]
}

tsconfig.jsonを用意したら、後は$ tsc --project ./または$ tsc -p ./とすることでコンパイルを行うことができます。直接tsconfig.jsonを指定するのではなく、tsconfig.jsonがあるディレクトリを指定するのがポイントです。

設定可能な項目については公式wikiのtsconfig.jsonとコンパイラオプションの項目を参照してください。

型定義ファイルマネージャ

TypeScriptでコードを書くにあたり、もっともつらく、面倒なことを示しておきます。

TypeScriptはJavaScriptのsupersetであるので、既存のjQueryやAngularJSなどのJavaScript製ライブラリも利用することができます。しかしながら、JavaScriptで書かれているということは、ソースコードの字面上からなんというプロパティがあって、なんという関数があって、変数の型が何か、なんて全然わからないわけです。そのため、既存ライブラリをTypeScriptで使おうと思ったら、人間が型の情報を手書きしてライブラリの全体像をTypeScriptコンパイラに教えてやらねばならないのです。

型情報を記述したファイルを型定義ファイルと呼んでいます。有名どころのライブラリであれば、DefinitelyTypedというリポジトリで型定義ファイルを見つけることができます。たとえば、jQueryやAngularJS、Node.jsの型定義ファイルなどはすでに成熟したものが存在しています。これら有名どころのライブラリはただ単にダウンロードしてきて使えばよいですが、マイナーなライブラリや非公開の社内ライブラリの場合は、自分で型定義ファイルを書き起こさなければなりません。

とはいえ、たとえばjQueryであれば最低限declare var $: any;という型定義を書いておけば、コンパイルを通すことはできます。充実した型定義は開発を加速しますが、最初のうちはざっくりした定義を与えておき、後から必要に応じて徐々に拡充していけば十分です。その過程でバグもより多く見つかるようになっていくことでしょう。

これら、型定義ファイルを上手に管理するためのツールも記事内で紹介します。

dtsm

手前味噌ですが、筆者（わかめ）が製作している型定義ファイルマネージャです。詳しい紹介は（ちょっと古いですが）Qiitaの記事を参照していただければと思います。

TypeScript界でデファクトのtsdに対する優位点として、型定義ファイルを集めたリポジトリをまるごとcloneしてくるため、一度cloneした後は高速に動作し、オフラインでの検索やインストールが可能です。また、npmやbowerといった広く使われているパッケージマネージャと使い方をなるべく似せてあるため、学習コストが低くすみます。

npm install -g dtsmでインストールできます。

一番シンプルな使い方は、dtsm search ui-routerなどで検索し、dtsm install angular-ui-router/angular-ui-router.d.tsやdtsm install angular-ui-routerで型定義ファイルを取得します。取得した型定義ファイルはtypingsディレクトリに格納されます。

型定義ファイルの更新などに簡単に対応できるようにするには、dtsm initでdtsm.jsonを作成し、dtsm install --save angular-ui-routerでdtsm.jsonに設定を書き込みます。更新はdtsm update --saveで行うことができます。

企業内に閉じたgitリポジトリ上で管理されている型定義ファイルなども参照させることができます。

tsd

TypeScript界でデファクトで使われている型定義ファイルマネージャです。GitHubのAPIを叩いて型定義ファイルを取得するため、たまに動作が遅い時があったり、企業などで同一IPアドレスからの利用が多くなるとRate Limitがかかってしまい、Tokenの取得や設定が必要になったりする場合があります。

npm install -g tsdでインストールできます。

一番シンプルな使い方は、tsd query "*ui-router"などで検索し、tsd install angular-ui-routerで型定義ファイルを取得します。取得した型定義ファイルはtypingsディレクトリに格納されます。

型定義ファイルの更新などに簡単に対応できるようにするには、tsd initでtsd.jsonを作成し、tsd install angular-ui-router --saveでtsd.jsonに設定を書き込みます。更新はtsd reinstall --overwrite --saveで行うことができます。

ビルドタスクとタスクランナー

TypeScriptプロジェクトを運用するために必要なタスクの紹介と、gruntとgulpの2つのタスクランナーについて取り上げていきます。筆者は普段gruntを使っているため、gulp周りについて改善できそうな箇所があったらサンプルリポジトリに対してpull requestなどいただけたらと思います。

最低限必要なタスクはたった2つだけです。

1つ目は、tsconfig.jsonのfilesプロパティを更新するためのgrunt-tsconfig-updateとgulp-tsconfig-updateです。grunt版は僕が、gulp版はlacoくんが作ってくれました。

2つ目は、tsc -p ./相当の操作をしてくれるgrunt-ts（5.0.0-beta.4以上）か、gulp-shellです。tscコンパイラに指定する内容自体がtsconfig.jsonによって大幅に簡略化されたため、grunt-tsもgrunt-shellに置き換えてしまってよいかもしれません。

これに、いくつかのタスクをオプションで追加してもよいでしょう。候補を挙げておきます。

よくないスタイルのTypeScriptコードを検出し教えてくれるtslintと、それを各タスクランナー用に切り出したgrunt-tslintとgulp-tslint。

TypeScriptコードにフォーマッタを適用しきれいにしてくれるtypescript-formatterと、それを各タスクランナー用に切り出したgrunt-typescript-formatterとgulp-tsfmt。

TypeScriptコードからドキュメントを生成してくれるtypedocと、それを各タスクランナー用に切り出したgrunt-typedocとgulp-typedoc。

dtsm, tsdとgrunt-dtsm、grunt-tsd、gulp-tsd。

大部分がgrunt-shellやgulp-shellからの呼び出しでもよいような気がしますね…。

エディタ

最後にエディタです。記事で紹介するVisual Studio Code、Atom以外にも多様な選択肢があるため、自分が馴染んでいるエディタやIDEにもTypeScript用プラグインが存在しないか試してみるとよいでしょう。

多様な選択肢がある理由ですが、TypeScriptは単なるコンパイラ以外のさまざまな機能を持っています。たとえば、ソースコードをフォーマットする機能だとか、入力補完候補を生成する機能です。これら、エディタの機能実装をサポートする強力で便利な要素があるため、本家Visual Studioと比べ、遜色ない強力な補完機能を備えたエディタが多く存在しているわけです。

とはいえ、エディタやプラグイン毎にTypeScript本体への追従度や完成度に差があるため、「イマイチ使いにくいな…」と思ったら別のエディタを試してみるのがよいでしょう。

本記事では、筆者がメインで使っているVisual Studio CodeとAtomについて解説します。

Visual Studio Code

VSCはMicrosoftが作ってはいますが、Electron上に構築されたマルチプラットフォームのエディタです。本家Visual Studioと違い、プラットフォームの縛りはありませんし、無料です。オープンソースではないため、自力で機能追加やバグ修正ができないのは難点ではあります。

grunt-tsconfig-updateかgulp-tsconfig-updateとの併用が前提になりますが、正しいtsconfig.jsonさえ作ってしまえばさすが本家Microsoft製だけあって、期待どおりに正しく入力補完やエラーの報告を行ってくれるようになります。特に強い要望がなく、gruntまたはgulpの利用に抵抗がないのであればVSCを最初に試してみるのがよいでしょう。

Atom + atom-typescript

AtomはGitHubが作っているエディタです。atom-typescriptプラグインを併用することで大変便利なTypeScript開発環境として利用することができます。

まとめ（開発環境編）

タスクランナーの設定とエディタの設定が終わり、JavaScriptとは比較にならぬリッチな開発環境を手に入れられたことでしょう。何か疑問や要望がある場合、サンプルリポジトリのIssueまでお寄せいただければ、筆者の人生がつらくなっていなくてTypeScriptに飽きていない限り、対応できると思います。今のところTypeScriptは3年近く飽きていないので、もうしばらくは飽きないと思うんですよね。

次回は、いよいよECMAScript 2015なコードをTypeScriptで書き始めていきます。

わかめです。これから、TypeScriptを使ってECMAScript 2015スタイルのコードを書く方法を紹介します。連載の初回となる本稿では、ECMAScript 2015やTypeScriptの魅力について、TypeScript用エディタの案内をしていきます。

TypeScriptとは？

TypeScriptはMicrosoft社が開発しているAltJSの1つです。AltJSとは、ある言語Xから、JavaScriptへと変換（トランスパイル）して使う言語の総称です。Typeという名の通り、JavaScriptの世界に静的な型付けを持込み、JavaやC#のようにコンパイル時に整合性のチェックを行うことができるようにしたものです。

見事チェックにパスしたら、TypeScriptからJavaScriptへと変換され、JavaScriptとして実行できる、という按配です。

TypeScriptは全くの新言語、というわけではありません。ECMAScript 5のsupersetとして設計されているため、皆さんが慣れ親しんだJavaScriptの構文に少しの+αを加えた言語がTypeScriptです。ECMAScript 5のsupersetなのですが、設計当初よりクラスなどのECMAScript 2015の要素も含んでいました。ゆくゆくはECMAScript 2015のsupersetにもなっていくことでしょう。

また、多くのECMAScript 2015用の構文をECMAScript 5の構文に変換して出力することができるため、現在のECMAScript 5をサポートしている（つまりほとんどの）ブラウザで動作させることが可能です。ECMAScript 5を改良すべく生まれたECMAScript 2015の仕様を先取りし、既存のブラウザ上で使いはじめることができる環境として、TypeScriptは魅力的でしょう。

TypeScriptのECMAScript 5の範囲での説明は、型の国のTypeScriptなどを参照してください。

TypeScriptとECMAScript 2015

ECMAScriptというのは、JavaScriptの仕様の元になる仕様です。現在、多くのブラウザではECMAScript 5の仕様にもとづき実装が行われています。2015/06/18にECMAScript 6th editionとして、ECMAScript 2015が策定されました。ECMAScript 2015という名前よりも、ECMAScript 6や、もっと縮めてES6という名前のほうが目にする機会が多いかもしれません。

これにより、今後ブラウザでのECMAScript 2015のサポートの進みが早くなっていくものと考えられます。現在の各ブラウザでのES6の機能の実装状況はes6 compat tableで確認するのが便利でしょう。

ECMAScript 2015には、言語仕様に素敵な要素が多く追加されています。いくつかを確認していきましょう。コード例を見て、「え、これ今までできなかったの？」と思ってしまうかもしれません。TypeScriptなら、今使えます。

• letでブロックスコープ

let str = "外側の変数";
console.log(str); // 外側の変数 と表示される
{
  let str = "内側の変数"; // このブロックでだけ有効
  console.log(str); // 内側の変数 と表示される
}
console.log(str); // 外側の変数 と表示される！戻ってる！

• constも使える

const str = "test";
str = "re-assignment"; // 仕様上SyntaxErrorになる。ブラウザによっては未実装で単に無視される。

• prototypeの代わりにclass構文！

class SampleA {
  constructor() {
    this.name = "vvakame";
  }

  hi() {
    console.log("Hi! " + this.name);
  }
}

// 上記と等価なECMAScript 5なコード
function SampleB() {
  this.name = "vvakame";
}
Object.defineProperty(SampleB.prototype, "hi", {
  enumerable: false,
  configurable: true,
  writable: true,
  value: function () {
    console.log("Hi! " + this.name);
  }
});

// 実行結果は同じ
new SampleA().hi();
new SampleB().hi();

• アロー関数でわかりやすいthisの振る舞い

"use strict";

function Sample() {
  // this.name を設定する
  this.name = "vvakame";

  // 普通の関数とアロー関数で this の値を比べてみよう！
  var func1 = function() {
    console.log("func1: " + JSON.stringify(this));
  };
  var func2 = () => {
    console.log("func2: " + JSON.stringify(this));
  };

  // func1: undefined と表示される
  // 非直感的。いやわかるでしょ？という人はJavaScript慣れしています！
  func1();

  // func2: {"name":"vvakame"} と表示される
  // 直感的！
  func2();
}

new Sample();

• デフォルトパラメータ、便利です

function hello(word = "ECMAScript 2015") {
  // word が指定されなかった場合のデフォルト値を指定できる
  console.log("Hello, " + word + "!");
}
hello("JavaScript"); // Hello, JavaScript! と表示される
hello();             // Hello, ECMAScript 2015! と表示される

• 文字列連結もお手軽に！

let name = "vvakame";
let like = "cat";

console.log(`${name} ♥ ${like}`); // vvakame ♥ cat と表示される

なぜTypeScriptか？

さて、本記事ではタイトルの通り、TypeScriptを推していくわけですが、他の選択肢についても言及していきます。読者自身が何をほしいか、どうやって自由自在にコードを書きたいか、作りたいものがどれくらいの規模なのか、それぞれをよく考えて適切な選択をしていただけるといいなと考えています。もちろん、おすすめはTypeScriptですが、読者層別におすすめのツールを取り上げていきます。

Babel

Babelは旧名が6to5と呼ばれていたツールで、sebmck氏によって開発されています。Babelはソースコードのコンパイルが必要なツールで、通常foo.es6というファイルをfoo.jsに変換します。

現在ECMAScript 2015や、さらに次のECMAScript 7でコードを書くには一番進んでいて、将来のブラウザでもそのまま動く可能性が高いと言えます。現在のJavaScript(ECMAScript 5)に言語としての不満がない人や、Ruby on Railsなどの動的型付けの言語+フレームワークで十分に開発できている人に向いているでしょう。

Playgroundも用意されているため、まずはブラウザ上で試してみるとよいでしょう。

Flow

FlowはFacebookが開発しているツールで、JavaScriptに対して静的な型チェックを提供します。Flow自体の開発言語はOCamlです。Flowの型チェックは、型推論や段階的な型付けを前面に押し出しているようです。JavaScriptのコード自体、関数や変数のユースケースから型を推論させることや、TypeScriptと同様に手で型の指定を記述することもできます。制作元が同じだけあって、FacebookのReactと組み合わせて利用することも考慮されているようです。

もし、Reactを使うようであれば、利用を検討してみてもいいかもしれません。

TypeScript

さて、最後に我らがTypeScriptです。TypeScriptは、Microsoftが3年近く前から開発し続けているツールです。TypeScriptはソースコードのコンパイルが必要なツールで、通常foo.tsというファイルをfoo.jsに変換します。

TypeScriptは静的型付けの言語で、コンパイル時に多くの整合性のチェックを行うことができます。例えば「Personクラスには必ずnameプロパティがある」とか「mapメソッドは第一引数に関数を取る」などがソースコードの字面上から解析できれば、それに違反している（つまりは間違った）コードを実行するよりも前の段階で検出することができます。これは、JavaやC#といった言語と同じ性質であると言えます。

反対に、静的型付けではない、動的型付けである言語はJavaScriptやRubyなどです。これらの言語は実行時に必要なプロパティやメソッドなどが存在していればよい、という態度です。静的・動的な型付けのどちらが優れているということはありませんが、その言語を使う個人や組織毎に得手・不得手があるでしょう。

別な切り口として、IDEやエディタをどの程度使っているかも検討材料になります。静的型付けの言語では実行せずともどういうプロパティやメソッドがあるかがわかります。そのため、IDEによる強力な支援が得られやすいのです。

例えば、str.と打った時に利用可能なメソッドの一覧が提示されたり、変数やメソッドのリネームが一発でできたり、関数の参照元を全てリストアップするなどの作業を行うことができます。

反対に、動的にメソッドが増えたりする言語では正確なサジェストを行うのが大変難しいです。例えば、RubyのActiveRecord（ORマッパライブラリ）では、DBのテーブルのカラムに合わせて利用可能なメソッドが増えたりします。便利といえば便利ですが、IDEがライブラリのすること全てを把握してプログラムとして実行することなく呼び出し可能なメソッドの一覧を正しく提示することは現実としては不可能でしょう。

静的型付けな言語ではコンパイル時に検査されるおかげで、リファクタリングも抜け漏れなくできているという勇気が持てます。JavaScriptを書いている時に「テストを書き足りていないのではないか」「実行時にundefinedなプロパティを触ってしまいエラーになるのではないか」という恐怖を感じたことはありませんか？TypeScriptではこの恐怖をかなり減じ、勇気あるリファクタリングを行うことができます。常にきれいなコードを保つ足がかりをTypeScriptは提供してくれるのです。

Playgroundも用意されているため、まずはブラウザ上で試してみると良いでしょう。

なお、WebComponentsが流行ったほうが、Reactが主流の未来より僕は楽だよ派の筆者としては遺憾なのですが、TypeScript 1.6でJSXサポートが入る予定です。

エディタの紹介

TypeScriptはコンパイラ自身にLanguage Serviceという、まさにエディタのためのような機能が組み込まれています。TypeScriptを開発するための総本山（なにせMicrosoft製ですからね）であるVisual StudioでもこのLanguage Serviceから得た情報を元に処理しています。つまり、TypeScriptでは数多くのエディタでVisual Studio相当の入力補完や、フォーマットなどが得られるようになっているのです。

いくつか、箇条書きで紹介していきます。

• Visual Studio
  MicrosoftのIDEの最有力候補。NuGetなど独自の生態系があるが最近だいぶOSS側に歩み寄ってきた。残念ながらWindowsでしか動かない。
  
  
• Visual Studio Code
  最近新登場したIDE。Windows, Mac, Linuxで動作する。Previewなだけあってまだまだ機能が足りないが十分動く。Macユーザである筆者のメイン環境その1。余談だが、内部的にGitHub社製Atomが使っているElectronというフレームワークを使っていて、IDE全体がHTML+JavaScriptで作られている。
  
  
• atom-typescript
  GitHub社製のAtomエディタ用のプラグイン。筆者のメイン環境その2。
  
  
• eclipse-typescript
  Eclipse用プラグイン。かなり長期間開発が継続されている。Eclipseユーザなら検討の価値があるかも。
  
  
• TypEcs
  Eclipse用プラグイン。同上。
  
  
• typescript-tools
  エディタそのものではないが、TypeScriptのLanguage Serviceをツール化したもの。vimやemacs、Sublime Text 3用のプラグインから利用されている。
  
  
• WebStorm
  JetBrains社製のIDE。IntelliJ IDEAやPyCharm, PhpStormの仲間。ここに書いたが、WebStorm 10の時点ではLanguage Serviceを使っておらず、独自に解析しているためTypeScript用という観点で見た時は一歩劣る。筆者の旧メイン環境。

まとめ

TypeScriptの環境を作り、しばらくコードを書いてみて、あまりに窮屈すぎる！エディタの恩恵を感じない！と思ったらbabelを使ってみるとよいでしょう。

次回は開発環境の構築と、TypeScriptを取り巻く周辺ツールについて解説します。