Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
111
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

Organization

TypeScript 1.5.3 変更点

TypeScript 1.5.3が出ました!
今回のアップデートはかなり多くの更新を含む、大規模なアップデートであると言えます。
↑ここまで前回のコピペ

まさか、1.4.1から半年待つことになろうとは思いませんでしたね…。
alphaからbetaが1月なのに正式リリースが2ヶ月強ですよ。

'1.4.1':        '2015-01-16T17:55:29.237Z',
'1.5.0-alpha':  '2015-04-02T16:40:27.808Z',
'1.5.0-beta':   '2015-04-30T17:23:52.442Z',
'1.5.3':        '2015-07-20T14:47:42.460Z'

変更点は公式Blogにも書かれているが、ざっくりイカの通り。

公式WikiのWhat's new in TypeScriptも参考になる。

ES6サポート

まぁ普通にES6の解説とか探してみてください!で十分だと思うのでばっさり省略。
型周りでなにか疑問があればコメントに書いてもらえれば調べて書きます。

既存の外部モジュール(or 型定義ファイル)をes6 module syntaxで扱う

の、前にes6でのmoduleの書き方をおさらいしておきます。

// sub.ts
export function hi (word: string) {
    console.log(`hi ${word}`);
}
export default function (word: string) {
    console.log(`bye ${word}`);
}
// main.ts
import {hi} from "./sub"; // {hi, default as sub} とか sub, {hi} だと1行で書ける
import sub from "./sub";

hi("TypeScript");  // hi TypeScript と表示される
sub("JavaScript"); // bye JavaScript と表示される
// main.ts 別解
import * as sub from "./sub";

sub.hi("TypeScript");         // hi TypeScript と表示される
sub.default("JavaScript"); // bye JavaScript と表示される

OKですね。
TypeScriptのes6 moduleの偉いところは、--target es5などの時でも、CommonJSやAMDなどの外部モジュール形式に変換してくれるところです。
なので、1.5.3以降ではes6 moduleで書き、コンパイル時にCommonJSなどにするのが良いでしょう。

さて、逆に考えるとCommonJS形式などのJavaScriptでも、適切にes6 moduleによる型定義を与えてやればes6 moduleの書き方で扱うことができます。
しかし、現在のDefinitelyTypedにはまだまだes6 moduleの書き方をしている型定義ファイルは多くありません。というか皆無です。

なので、とりあえず * as foo の形式でfooにモジュールを束縛して使うのが今までの使い方とあまり差がなく、わかりやすいでしょう。

// test.d.ts
// 旧来の型定義ファイルの書き方!
declare module "test" {
    var str: (word: string) => void;
    export = str;
}
/// <reference path="./test.d.ts" />
// 前は import test = require("test"); と書いてた
import * as test from "test";

test("TypeScript");
/// <reference path="./test.d.ts" />
var test = require("test");
test("TypeScript");

なお、export = と等価なes6 moduleの書き方は存在していない(よね?)ため、しばらくはes6 moduleと旧来の書き方が混在した状態が続くでしょう。
(export defaultは export = とは微妙に異なる挙動です。)

namespace キーワード

TypeScriptにも今まで外部モジュール(1ファイル=1モジュール)と内部モジュール(関数でモジュール様の構造を作る)と呼ばれるモジュールの仕組みが存在していました。
しかし、ES6でmoduleというものが定義されまして、これは、今までのTypeScriptでいうと外部モジュールに相当します。
つまり、今後JavaScript界で単に "モジュール" と言えば、es6 module(=外部モジュール)を指すようになることは火を見るよりも明らか!
余計な混乱を生まぬよう、内部モジュールは今後、namespaceという名前にしようね!という変更です。
今後は、内部モジュールではなくnamespaceを使うようにしましょう。

// 今まで
module foobar {
    export function hi(word: string) {
        console.log(word);
    }
}
foobar.hi("TypeScript");

// これから
namespace buzz {
    export function hi(word: string) {
        console.log(word);
    }
}
buzz.hi("TypeScript");

Playground

UMDとSystemJS

UMDSystemJSのサポートが追加されました。

UMD

Universal Module Definitionの略。
仕様というよりかは、モジュールを外部にexportする時のデザパタと言ったほうがいいだろう。
TypeScriptの出力では、AMDとCommonJS両方に対応したJSを出力できます。

TypeScriptコードとコンパイル結果のJSを示す。

import sub = require("./sub");
sub("");
(function (deps, factory) {
    if (typeof module === 'object' && typeof module.exports === 'object') {
        var v = factory(require, exports); if (v !== undefined) module.exports = v;
    }
    else if (typeof define === 'function' && define.amd) {
        define(deps, factory);
    }
})(["require", "exports", "./sub"], function (require, exports) {
    var sub = require("./sub");
    sub("");
});

SystemJS

jspmが使ってるモジュールローダらしい。
トランスパイラはTypeScriptで間に合ってます…感が高い。

TypeScriptコードとコンパイル結果のJSを示す。

import sub = require("./sub");
sub.hi("");
System.register(["./sub"], function(exports_1) {
    var sub;
    return {
        setters:[
            function (_sub) {
                sub = _sub;
            }],
        execute: function() {
            sub.hi("");
        }
    }
});

やりたいことはわからんでもない。

tsconfig.json

大昔からある仕様として、 tsc @sample.tscparams のように書くと、sample.tscparamsファイル内に書いてある内容がそのままtscのオプションとして利用される、という機能がありました。
tsconfig.jsonはそれに似た仕様です。

tsconfig.jsonは、TypeScriptコンパイラに与えるオプションの設定としてだけではなく、AtomやVisualStudioCodeなどのエディタとコンパイラへの設定を共有するのに便利です。
詳細は公式のWikiを参照してください。

ざっくり以下のような書式です。

tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true
    },
    "files": [
        "foo.ts"
    ]
}

compilerOptions に書けるものは、tscコマンドに渡せるオプションと同一のようです。
また、filesにコンパイル対象のファイルを全て記述します。
これにより、/// <reference path="./hoge.d.ts" />というリファレンスコメントから逃れることができます。

tsconfig.jsonは基本的に1プロジェクト1ファイルですが、例えばlibとtestの2フォルダそれぞれに置くこともできます。
tscコマンドからtsconfig.jsonを読み込む時は、--project オプションでtsconfig.jsonのあるフォルダを指定します。

複数設定を書くのもめんどいですし、そのうちgruntやgulpからもtsconfig.jsonを参照するスタイルが流行るのではないでしょうか。

いちいちfilesを書くのはめんどくさい!という人は、atom-typescriptを使うと、filesGlobでパターンを指定するとエディタの保存時にfilesを更新してくれます。
また、TypeScript 1.6ではexcludeによる除外指定が導入されます。

Decorators

ざっくり言うとJavaのアノテーションのような構文で、処理を差し挟めるようになりました。
デコレータは以下の箇所に使うことができます。

  • クラス定義
  • インスタンスメソッド
  • インスタンスプロパティ
  • インスタンスのget/setアクセサ
  • メソッドの引数
  • クラスメソッド
  • クラスプロパティ

コンパイルには --experimentalDecorators オプションが必要です。

var constructorNames: string[] = [];

function collectConstructorName(sampleClazz: any) {
    constructorNames.push(sampleClazz.name);
    return null; // 値を返すとその値でクラスそのものを置き換えることもできる
}

@collectConstructorName
class Foo {
}

alert(JSON.stringify(constructorNames)); // ["Foo"] と表示される

変換結果は長いので、Playgroundで確認してください。

デコレータの使い道は色々あって、想像力次第で色々と便利なことや邪悪なことができるでしょう。
筆者は、本来継承できないオブジェクトを無理やり継承するなどして有効活用しています。

なお、--emitDecoratorMetadata オプションを併用することで型情報を実行時に(ちょっぴり)参照できるようになるので、興味があれば検証してみるといいでしょう。
筆者は普通にTypeScriptのASTを読んで実行時情報として出力するツールを作ったほうがよくない?と思いました。

これからのベストプラクティスまとめ

import foo = require("foo"); 形式の外部モジュール使うな!es6 module syntax使え!
内部モジュール使うな!namespace使え!
なるべくtsconfig.json使おう!
よろしくお願いします ┏○

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
111
Help us understand the problem. What are the problem?