TypeScriptハンズオン第1回テキスト
Download as PPTX, PDF1 like1,544 views
職場で開催したハンズオンの資料。
![atom-typescriptインストール
1. Atomを起動をしたら設定画面を開く
• macOSの場合：メニューバー[Atom]→[Preferences]
• Windowsの場合：メニューバー[File]→[Settings]
2. Preferences画面の左側ペインからInstallタブを開く
3. "atom-typescript"パッケージを検索
4. [Install]をクリック
作業
①
②
③
④](https://image.slidesharecdn.com/typescript1-170204011913/85/TypeScript-1-18-320.jpg)
![Atomでプロジェクトをオープン
① [File]→[Add Project
Folder]をクリック
② [Open Folder]ダイアログ
で、先程mkdirしたディレ
クトリを選択
③ プロジェクト＝フォルダ名
を右クリック→[New File]
をクリック
④ テキストボックスが表示さ
れるので"tsconfig.json"と
入力して[Enter]
作業](https://image.slidesharecdn.com/typescript1-170204011913/85/TypeScript-1-40-320.jpg)
![gulpfile.jsの続きをコードする前に…
タスク定義の基本①
// 1. 依存タスクありの場合
gulp.task(<タスク名>, [<依存タスク0>, <依存タスク1>, ...], () => {
return gulp.src([<入力のパス0>, <入力のパス1>, ...])
.pipe(<フィルタ0>)
.pipe(<フィルタ1>)
/* …中略… */
.pipe(gulp.dest(<出力先のパス>));
});
// 2. 依存タスクなしの場合
gulp.task(<タスク名>, () => { /* …中略… */ });
パイプライン](https://image.slidesharecdn.com/typescript1-170204011913/85/TypeScript-1-43-320.jpg)
![gulpfile.jsの続きをコードする前に…
タスク定義の基本②
// 3. 複数のパイプラインを統合する場合
gulp.task(<タスク名>, () => {
return merge([
gulp.src(...) /* 中略 */ .pipe(gulp.dest(...)),
gulp.src(...) /* 中略 */ .pipe(gulp.dest(...)),
/* …中略… */
]);
});](https://image.slidesharecdn.com/typescript1-170204011913/85/TypeScript-1-44-320.jpg)
TypeScriptハンズオン第1回テキスト
- 2. はじめに
- 3. 自己紹介 名前 藤谷 瑞樹 所属 リクソル キャリア開発G 専攻 社会学 好きなもの P・ブルデュー、G・バシュラール、 M・ブロック、F・ジャコブズ、 V・ウルフ、J・オースティンなど 苦手なもの 人間の多い場所、人間相手に何か すること 最近の動向 こたつでヤドカリ生活
- 4. この資料における用語法 用語 正式名 説明 JS JavaScript 言わずもがなであるが、主要Webブラウザで実行可能なスクリプ ト言語。 ES ECMAScript JavaScriptをもとにECMA標準として定義されたスクリプト言語仕 様。JS以外にActionScriptやTypeScriptなどの実装がある。改訂に よる言語仕様強化が繰り返されており、TS3、TS5、TS6＝ TS2015、TS7=TS2016と呼称されている。 TS TypeScript ESの実装の1つであり、JSの（ほぼ）スーパーセットというべき 言語。コンパイルを通じてJSに変換（トランスパイル）される。 端末 コマンドプロン プト、etc... Windowsであればコマンドプロンプト、macOSであればターミナ ル、Linuxであれば…ディストロによりけり。記述の便宜上の名称 として「端末」を用いる。 なお、本文やサンプルコードに登場するディレクトリ区切り文字は、各自 が使用しているOSに合わせて適宜読み替えてほしい。
- 5. 開催概要 • 目的 • TSの超概要と導入メリットの呈示 • TS開発をはじめるための環境構築の方法の呈示 • 日時と会場 • 第1回 2017/01/30 • 第2回 2017/02/06 • 予備回 2017/02/13
- 6. コンテンツ • スコープ内 • TSの紹介 • TSのメリット（とデメリット）のリストアップ • 言語仕様の超概要の説明（ただしハイライトだけ！） • 開発環境の構築方法の説明 • スコープ外 • 土台としてのJSの言語仕様 • AngularやReactなどとの統合
- 7. 進め方 • ツールのインストールやコーディングとその合間に言語仕様や ツールに関する捕捉説明を行う。 • 第1回 • 開発に最低限必要になるツール群をインストールしつつ、TSの言語仕 様を中心に学んでいく。 • ゴール：TSをそれ単体としてコーディングし、トランスパイルして、 JSの既存リソースとともに使用できる状態。 • 第2回 • TSビルド＆テストするためのツール群をインストールしつつ、TS開 発を現実の開発体制全体のなかに組み込む方法を学んでいく。 • ゴール：Node.jsのツールチェインを利用して、ビルド＆テストを実 施でき、Java/C#のツールチェインやCI体制と統合する準備もできて いる状態。
- 8. 第1回
- 9. 何はともあれ環境構築！
- 10. Node.jsインストール※1 ① Node.js公式サイトにアク セス ② OS/CPUアーキに照らして 適切なインストーラを取得 ③ デフォルトの設定でインス トール ④ インストールが終わったら 端末で"node -v"コマンド を実行 ⑤ パスが通っていることと バージョン番号が想定通り であることを確認※2 作業 ※1 OS/サードパーティが提供するパッケージ管理システム（例：MacPorts）を通じたインストール方法もあ るが、ここでは公式インストーラを使う前提で話をすすめる。 ※2 macOSやLinuxなど複数のパッケージ管理方法が存在する環境では、先にインストールされていた異なる バージョンが、新たにインストールされたバージョンを「隠して」しまっていることがまま起こりうる。
- 11. Node.jsって何？ • Chromeブラウザに搭載されているJSランタイムであるV8を サーバサイドのアプリ開発に転用したものです。 • エンタープライズ向け開発の世界からするとあえてそんなこと をするメリットがさっぱりわかりません…。 • が、（RubyがRailsを通じて結果としてCoCを推進したように ※1）Node.jsは結果としてJSの世界にパッケージングとその成 果物の配布という仕組みをもたらしました。 • Node.jsのパッケージ管理システムであるnpmは、MavenやIvy、 NuGet、PyPIなどに相当するものです。 • TSのコンパイラ（tsc）や関連ツールもこのnpmを通じて配布 されています。 ※1 もちろんRuby（とNode.js）を揶揄するためにこの括弧書きをしている。私見ではあるが、RubyとNode.js はいずれも「集団開発するアプリのランタイムとして選択してはいけない」選択肢のうちの最たるものである。
- 12. npmコマンド一覧 主に使ってるものだけ！ コマンド 別の書き方 説明 npm help <cmd> サブコマンドのマニュアルを表示する npm init カレントディレクトリにnodeパッケージのプロ ジェクトを作成する。 npm i <pkg> npm install <pkg> npmリポジトリからパッケージをインストール する。 npm i -S <pkg> npm install --save <pkg> npmリポジトリから指定のパッケージを取得し プロジェクトにインストールする。同時にプロ ジェクトのpackage.jsonに実行時の依存性とし て登録する。 npm i -D <pkg> npm install --save-dev <pkg> npmリポジトリから指定のパッケージを取得し プロジェクトにインストールする。同時にプロ ジェクトのpackage.jsonにビルド/テスト時の依 存性として登録する。 npm i -g <pkg> npm install --global <pkg> npmリポジトリからパッケージを取得しシステ ムにインストールする。CLIを持つパッケージで あればnpmコマンド同様に端末から直接実行可 能になる。 ※注意：当然のことながら管理者権限（macOS やLinuxではroot権限）が必要になる。
- 13. はじめてのnodeパッケージ ① 端末を起動 ② "mkdir <path>"コマンドでサンプル・プロジェクト用ディ レクトリを作成 ③ "cd <path>"コマンドで作成したディレクトリをカレント ディレクトリに設定 ④ "npm init"コマンドを実行 ⑤ いろいろ聞かれるがすべてデフォルト（Enterキーを押すだ け）で通す ⑥ "ls"もしくは"dir"コマンドで"package.json"ファイルができ たことを確認 作業
- 14. Gulpをインストール ① "npm i -g gulp-cli"コマン ドでGulpのCLIをグローバ ル・インストール ② "npm i -D gulp"コマンドで GulpのFWをローカルかつ 開発時依存性としてインス トール ③ "type nul > gulpfile.js" （"touch gulpfile.js"）コマ ンドでGulpのタスク定義 ファイルを作成 作業
- 15. Gulpって何？ • Node.jsエコシステムでビルドなどの各種タスクを自動化する ために利用されているタスクランナーの1つ。 • Node.jsの標準ライブラリが提供するStreamオブジェクト※1を 土台にして、高速かつ抽象度の高いファイル操作を提供するの が特徴。 • CLIである"gulp-cli"と、タスク定義を行うためのFWである "gulp"の2パッケージから構成される。 • プロジェクト・ルートのファイル"gulpfile.js"でタスク定義を 行う。当然のことながらこのファイルをバージョン管理するこ とで、タスク定義自体をバージョン管理できる。 • TSのコンパイルだけでなく、JSの圧縮・難読化、LESS/SASS のコンパイル、ソースマップの作成など多種多様なタスクをこ なすことが可能。 ※1 Pipes and FiltersパターンのNode.jsにおける実装。JavaでいればStream<File>といったところ（ただし中 間処理段階ではファイル内容はあくまでもバッファ上にありFS上のファイル実体とは切り離されている。
- 16. Gulpは必須ですか？ • いいえ。必須ではありません。 • しかしtscを直接使用するのは煩雑なので一般に何らかのタス クランナーが必要で、今回はGulpを採用しました。 • 他の選択肢としてIDEに頼る方法やGruntなど他のCLIを使用す る方法があります。 • 私は前項で上げたGulpの特徴から他のツールより優れたものと してGulpの利用を推奨します。 ※1 Pipes and FiltersパターンのNode.jsにおける実装。JavaでいればStream<File>といったところ（ただし中 間処理段階ではファイル内容はあくまでもバッファ上にありFS上のファイル実体とは切り離されている。
- 17. Atomインストール ① Atom公式サイトにアクセ スして、OS/CPUアーキに 照らして適切なインストー ラを取得 ② デフォルトの設定でインス トール ③ インストールが終わったら （スタートメニューなどか ら）Atomを起動する 作業
- 18. atom-typescriptインストール 1. Atomを起動をしたら設定画面を開く • macOSの場合：メニューバー[Atom]→[Preferences] • Windowsの場合：メニューバー[File]→[Settings] 2. Preferences画面の左側ペインからInstallタブを開く 3. "atom-typescript"パッケージを検索 4. [Install]をクリック 作業 ① ② ③ ④
- 19. Atomって何？ • GitHubが開発・公開。 • Node.jsランタイムを土台にHTML＋JS＋CSSで構築された開 発向けテキスト・エディタ。 • コア・コンポーネント（フレームワーク）はElectronという名 前で、フレームワークそれ単体でも配布されている。 • AtomをベースにMiscrosoft社が開発・配布しているのがVisual Studio Code。
- 20. Atomは必須ですか？ • いいえ。必須ではありません。 • TSはnpmとtscとお好みのテキストエディタがあれば開発でき ます。 • しかし何と言ってもTSのTSたる所以である型情報に基づくサ ポートは欲しいですし、とくにmacOSやLinuxにおいてIDEの 揃いが悪いため（後述）、そしてOS依存の開発環境は極力回 避したいためにAtomを採用しました。 • 開発環境がWindowsに固定されているのであればVisual Studio 2013以降を使用するのでもよいでしょう。
- 21. ツールの主な選択肢 名称 無償？ OS非依存？ 説明 Visual Studio NO NO VS2013.2以降TSをサポートしている。開発環境として Windows OS以外を想定していないのであれば選択肢に 入る。無償版の利用には制限がある※1。 WebStorm NO YES IntelliJファミリー。サーバサイドの開発にIntelliJを使用 しているならば選択肢に入る。 Eclipse YES YES TypEcsなどいくつかプラグインがあるが明らかに活発で ない。しかし直近ではEclipse本体がnpmやGulpなどとの 統合を意識しているようで…ようするに今後に期待。 VS Code YES YES Microsoft社が開発するAtomベースのテキストエディタ。 VSには機能的に劣るもののTSのコンパイルなどはこなせ る。 Atom YES YES GitHubがNode.jsランタイムをベースに開発し公開して いるテキストエディタ。コミュニティが開発・公開して いる各種パッケージ（プラグイン）により簡単に機能拡 張ができる。 ※VS Code・Atom以外にもTSをサポートするエディタはある。 ※1 この点については右の記事を参照のこと：http://www.buildinsider.net/hub/insidersbreak/2014112101
- 22. TSの超概要
- 23. TSのプロフィール • Miscrosoft社により開発され ているプログラミング言語。 • 2012年ころに登場し、現在も 活発にリリースがされている。 • AltJSにして、JSのスーパー セット。 • コンパイルによりJSファイル に変換（トランスパイル）さ れる。
- 24. AltJSって何？ • 新しい千年紀の最初の10年が終わらんとするころ登場。 • その名の通りJavaScriptを置き換えようとする思想/実践の総称。 • 一般にコンパイラがJavaScriptコードを生成する。 • ただし動機はいろいろ、有用性もいろいろ。 補足
- 25. AltJSの動機/形態 • 勉強会で紹介してきた種々の課題克服 • JavaScriptコーディングの省力化 • コンパイラ言語との統合 構文/パラダイム を置換え 構文/パラダイム を拡張 補足
- 26. AltJSの例 言語名 開発元 説明 CoffeeScript Jeremy Ashkenas AltJSの嚆矢となった言語。便利な構文/ショートハンドの導入。それと不可 分のコードの曖昧性の急拡大（XML/JSONに対するYAMLのようなもの）。 ようするに状況は却って悪化。 ClojureScript Rich Hickey JVM上で稼働するLisp方言であるClojureのコードを元にJavaScriptコードを 生成する。Clojureの売りは並列分散処理のはずだが…。 Dart Google クライアントサイドにランタイムが必要。つまりJavaScriptの糖衣構文では なく、独立した言語。 TypeScript Microsoft JavaScriptのスーパーセットであり、ECMAScript v6以降の先行実装でもあ る。後程さらに詳しく取り上げる。 Scala.js École polytechnique fédérale de Lausanne /Typesafe JVM上で稼働するOOP+FP言語であるScalaのコードを元にJavaScriptコー ドを生成する。Java/C#以上に強力な型システム、高度な型推論、にも関わ らずシンプルな記法、内部DSL、強力な標準APIといったScalaの特徴をそ のまま移植※1。当然の結果としてものすごいファイルサイズになる。 ※1 Scala.jsについてはこちらも参照のこと： http://m12i.hatenablog.com/entry/2015/07/20/104347 補足
- 27. AltJSの実行時エラー解析 • AltJSには以下の2つのコードが存在することになる： A) もともとのソースコード（非JS） B) コンパイル後のソースコード（JS） • 実行時のエラーはもちろんB側で起きる。 • エラーを解析するには、B側のコードのエラー箇所がA側の コードのどこに対応するかを知る必要がある。 • この対応付けを実現するのが、コンパイラにより生成され る.mapファイル※1。 • .mapに対応したブラウザではエラー発生時にもともとのコー ドの位置情報を表示してくれる。 ※1 .mapファイルはjQueryなどのライブラリでも利用されている。この場合.mapはライブラリのもとのソース コードとそれをminifyしたコードとを対応付ける（たぶん歴史的にはこの利用法が先行する）。 補足
- 28. TSの2本柱 静的型付け • 型宣言（クラスやインター フェースの宣言）を行える • 変数、引数、戻り値すべての 型注釈が行える →IDE/エディタがJava/C#同 等レベルの入力支援を行える。 →品質・生産性UP ES新仕様の取り込み • ESの新仕様を使用できる （それらは新仕様をサポート しないブラウザでも実行可能 なJSコードに変換される） →ラムダ式、async/awaitなど 高度な機能を利用できる。 →生産性UP
- 29. TSのJava/C#っぽい部分 ローレベル • classベースのOOP言語 • 静的型付け • アクセス修飾子 • モジュール構造 • 列挙型 • ジェネリクス ハイレベル • ラムダ式 • 型推論※1 • async/await※2 • yield return ※1 Javaのように後方互換性を気にする必要のなかったTSでは、型推論も非常に高度なものとなっており、 コーディングの生産性向上に貢献している。 ※2 async/awaitはC#ではTask<T>を核としているが、TSではPromise<T>を核としている。いずれにせよ Ajaxを主とする非同期処理が多用されるJS/TSの世界では、必然的にコールバック関数が多様され、それがコー ドの可読性悪化のとなる。このためasync/awaitによる同期手続きの煩雑さの解消は大きな意味を持つ。 Promise<T>の概要については http://m12i.hatenablog.com/entry/2016/12/23/234556 などを参照のこと。
- 30. Promise<T>って何？ A_____社のアーキテクチャはもちろん、正真正銘のクライアン トサイドMVCを理解する上でも必須の知識。 • Promise<T>の概要： • JavaでいうところのFuture<T>、C#でいうところのTask<T>。 • 非同期に実行される何かしらの処理の完了を監視し、その結果を取得 するためのオブジェクト。 • サンプルコードは こちらの記事などを参照のこと。 • Async/awaitの必要性： • Ajaxを主とする非同期処理が多用されるJS/TSの世界では、必然的に コールバック関数が多様され、それがコードの可読性悪化のとなる。 • Promise<T>もまた完了通知と結果値の受け渡しにコールバック関数 を利用する。 • このためasync/awaitによる同期手続きの煩雑さの解消は大きな意味 を持つ。 補足
- 31. Java/C#よりすごい部分 • 構造的部分型（Structural Subtyping）≠継承に基づく部分型 • いわゆる「ダックタイピング」に対する構文サポート。 • ダックタイピングが「整合性の担保はAPI開発者とAPIユーザ双方の努 力次第」なのに対して、構造的部分型は「整合性はコンパイラが保証 する」。 • デコレータ • Pythonにもあるアレ。 • JavaのAnnotation/C#のAttributeと異なり実装部を持つ。 • いずれにせよ対象の型や型のメンバーにAOPを行うもの。 • コンストラクタ引数によるインスタンス・メンバ宣言 • Scalaにもあるアレ。
- 32. メリデメ 「すごいのはわかったけど、それで何がうれしいの？」 • メリット： 集団開発の観点で生産性・品質のUPに大きく貢献。 • 静的型付けを土台とした強力なIDEサポート。 • async/awaitなど強力な糖衣構文による煩雑さの隠蔽。 「そんなのあって当たり前じゃん？」 →その「当たり前」がなかったのが従来のJSの現実。 • デメリット： • 学習が必要。 • ツールチェインの準備が煩雑。
- 33. デメリットに対する反論 • 「学習が必要」 • 学習曲線はきわめて緩やか。Java/C#の言語仕様をきちんと理解して いれば細々した構文のちがい以外たいした断絶はないはず。 • 静的型付け機能に典型的なように、TSにおいて「学ばなくてはいけな いこと」は従来のJSであれば「言語支援がないので開発者が記憶力と コーディング力で担保しなくてはならないこと」だったものが多い。 • クライアントサイドMVCの登場以来JSコード量は飛躍的に増大してお り、結局のところ選択しないリスク/コストの方が大きいだろう。 • 「ツールチェインの準備が煩雑」 • これは言い逃れしにくい。 • トランスパイルという手順を踏む以上どうしても手間が増えるし、 ツールの栄枯盛衰もしばらくは止まないだろう。 • とはいえこの部分で頭を抱えるのはアーキテクトだけのはず。
- 34. 将来性 • 「メリットが大きいのはわかったけど、将来性あるの？」 • あります。 • その理由は： A) ベンダ側：Microsoft社が開発をしており継続的な開発・保守が期待 できる B) コミュニティ側：OSSをめぐるMS社の政策転換の結果コミュニティ も活発化し、関連ツールや書籍、Web上のHow-To記事も多く出 回っている
- 35. 移行しやすさ • 「将来性もあるとして、乗り換えできるかな…」 • 乗り換えはとてもしやすいです！ • その理由は： A) 開発側：従来のJSとJava/C#を理解していればTSも容易に理解でき ます。 B) ユーザ側：TSを動作させるのに特別な環境は不要。従来通りブラウ ザで動作します。
- 36. はじめてのTSプロジェクト
- 37. ディレクトリ構成 ├── node_modules （"npm i"により自動生成） ├── src （ビルド対象ファイルセット） │ ├── index.html （HTMLファイル。あとで作成） │ └── js │ ├── main.ts （TSファイル。あとで作成） │ └── sub.ts （同上） ├── target （ビルド成果物の出力先） ├── package.json （"npm init"により自動作成） ├── tsconfig.json （TS設定。あとで作成） └── gulpfile.js （Gulp設定。あとで作成） ※node_modulesとpackage.json、tsconfig.json、gulpfile.js以 外のパスは開発者が自由に決めるもの。
- 38. 依存性のインストール ① "npm i -D <pkg>"で以下の開発時依存性をインストール： • gulp（すでに実施済み） • gulp-rename • gulp-sourcemaps • gulp-typescript • gulp-uglify • merge-stream • typescript • @types/jquery ② "npm i -S <pkg>"で以下の実行時依存性をインストール： • es6-promise • jquery • requirejs ③ "npm i -g <pkg>"で以下のCLIをインストール： • serve 作業
- 39. なぜ-S/Dを指定するの？ • 依存性を"package.json"に記録するためです。 • そうしておけばGitやSVNで"node_modules/"配下の依存性の ファイル実体ごとバージョン管理する必要がなくなります。 • "npm i"（引数なし）を実行すると"package.json"に記録された 情報をもとに依存性が一括ダウンロードされます。 ※開発時依存性は"package.json"の"devDependencies"に、実行 時依存性は"dependencies"にそれぞれ記録されます。 補足
- 40. Atomでプロジェクトをオープン ① [File]→[Add Project Folder]をクリック ② [Open Folder]ダイアログ で、先程mkdirしたディレ クトリを選択 ③ プロジェクト＝フォルダ名 を右クリック→[New File] をクリック ④ テキストボックスが表示さ れるので"tsconfig.json"と 入力して[Enter] 作業
- 43. gulpfile.jsの続きをコードする前に… タスク定義の基本① // 1. 依存タスクありの場合 gulp.task(<タスク名>, [<依存タスク0>, <依存タスク1>, ...], () => { return gulp.src([<入力のパス0>, <入力のパス1>, ...]) .pipe(<フィルタ0>) .pipe(<フィルタ1>) /* …中略… */ .pipe(gulp.dest(<出力先のパス>)); }); // 2. 依存タスクなしの場合 gulp.task(<タスク名>, () => { /* …中略… */ }); パイプライン
- 44. gulpfile.jsの続きをコードする前に… タスク定義の基本② // 3. 複数のパイプラインを統合する場合 gulp.task(<タスク名>, () => { return merge([ gulp.src(...) /* 中略 */ .pipe(gulp.dest(...)), gulp.src(...) /* 中略 */ .pipe(gulp.dest(...)), /* …中略… */ ]); });
- 50. sub.tsのコード 作業
- 51. 気がついた？ • 各種キーワードの入力候補が表示された（当たり前） • インターフェースが宣言するメンバをクラスが実装していない 場合エラーが表示された（TSならでは） • クラスの実装では関数の戻り値型の注釈が省略できた（TSな らでは） • コンストラクタ引数にprivate/publicを付けることでプロパ ティの宣言を省略できた（TSならでは） • TSファイルを上書き保存すると都度自動でJSファイルが作成 された（tsconfig.jsonとAtomのおかげ） • 一旦JSファイルを生成したあとTSファイルに変更を加えると Atomの画面下部に"JS Outdated"と表示された（atom- typescriptのおかげ）
- 53. 気がついた？ • importで存在しないモジュールやモジュール・メンバーを指定 するとエラーになった（TSならでは） • sub.Greeterやg.greet()（TSで定義した型）を入力する過程で 入力候補が表示された（TSならでは） • $(...).text(...)（JSで作成されたサードパーティAPI）を入力す る過程で入力候補が表示された（TSならでは） • showMessage(...)を入力する過程で誤った型の値を指定すると エラーになった（TSならでは）
- 54. ちょっと書き換えてみよう • showMessage関数の宣言を書き換えたらどうなる？ • 前： function showMessage(g : sub.Greeter) • 後： function showMessage(g : { greet : () => string }) • showMessage関数の呼び出しを書き換えたらどうなる？ • 前： showMessage(new sub.GreeterEn()); • 後1： showMessage(new sub.GreeterX('こんにちはみなさん')); • 後2： showMessage({ greet : () => 'こんにちはみなさん' }); • gulpfile.jsのtypescript(...)フィルタの後ろに以下の2フィルタを 追加したらどうなる？ • .pipe(uglify()) // 圧縮・難読化 • .pipe(rename({suffix: '.min'})) // ファイル名編集 作業
- 55. 動かしてみよう • 端末で"gulp"コマンドを引数なし（あるいは"gulp default"）で 実行 • その後"serve target"コマンド実行 • Webブラウザ（IEの場合はバージョン9以上）で "http://localhost:3000/"にアクセス 作業
- 57. モジュール依存性解決の選択肢 名称 説明 CommonJS JSのモジュール化およびその実行時依存性解決のための仕様。Node.jsはこれ をサポート。gulpfile.jsのrequire(...)はこれに該当。 AMD Asynchronous Module Definition。JSのモジュール化およびその実行時依存 性解決のための仕様。Web開発で古くから使われてきた。今回TSコードで使 用したの（コンパイラオプションで他方式も選べる）。実装はRequireJS。 Browserify CommonJS形式で定義されたモジュールおよびそのインポートのコードを解 析し、ビルド時点で依存性解決を実行、結果を単一ファイルに変換（バンド ル）するツール。 Webpack Browserifyをさらに機能拡張したようなツール。JSコードだけでなくCSS （LESS/SASS含む）なども含めて、ファイルのバンドルを行うことが出来る。 ※1 .mapファイルはjQueryなどのライブラリでも利用されている。この場合.mapはライブラリのもとのソース コードとそれをminifyしたコードとを対応付ける（たぶん歴史的にはこの利用法が先行する）。 補足
- 58. きょうはこのへんで…
- 59. きょうはこのへんで… • 今回は： • TSの開発環境を構築する方法を学んだ • TSの静的型付け言語としての優位性を確認した • 次回は： • TSでSPAを作る方法を学ぶ • TSコードをUTする方法を学ぶ ※時間と紙幅の都合でNode.js、Gulp、そしてもちろんTSについても説明 を大幅に端折っています。それを埋めるのは皆さんの自己学習です。
- 60. 参考文献 書名 JavaScriptプログラマのための 実 践的TypeScript入門 著者 川俣晶(著)、井上章(監修) コメント Java/C#を理解している開発者か らするとやや冗長な説明もありま すが、TSの仕様や優位性について （JSの闇についても）よく理解で きると思います。