Introduction to TypeScript March, 2019 Kenju Wagatsuma Cookpad Inc. 

Why “TypeScript”? 

なぜ TypeScript を導入するのか 目的 ・静的型付けを導入し、アプリの品質を向上させるため ・静的型付けを JavaScript の世界に導入する中で一番妥当な選択肢が、TypeScript 前提 開発基盤やテスト環境は昨年一年間を通して大きく整備してきた、残りのピースが静的型付け ・依存ライブラリの取捨選択および最新版へのアップデート ・副作用のある DOM テストの疎結合化および Coverage の向上 ・JSHint -> ESLint や Phantomjs -> Headless Chrome などのツールチェーンの移行 

アプリの品質を高めるためのベース　 ドメイン知識 （業務フローへの理解 / 知見共有会 / ビジネス目標の浸透） 静的型付け （TypeScript Compiler） 静的解析 （ESLint） 可読性 （DefinitelyTyped / 独自の型定義） 単体テスト・結合テスト （Karma / Jasmine） デプロイ自動化 ライブラリの 定期アップデート リファクタリング のチーム文化醸成 

なぜ社内広告 SDK から導入するのか 課題 前提となるドメイン知識が広く求めれる ・Programmatic Advertising / Header Bidding / 社内配信フロー ・したがって、品質担保のみならずコードの可読性も求められる ・JSDoc によるドキュメントの保守性が限界 3rd Party Librariesが多い ・Header Bidding だけでも apstag / googletag / pbjs などの 3rd Party Libraries に依存 ・その他動画広告 SDK や第三者配信タグ 

なぜ facebook/flow ではないのか エコシステムの優越性 ・エディター拡張機能などの周辺ツールチェーンが TypeScript より未熟 ・世間的にも TypeScript 導入企業が増えてきて、ユーザーボリュームも Flow より多い 持続的開発性 ・Microsoft で開発されている TypeScript の方が安心材料が多い メンバーのスキルメリット ・技術選定者がプロダクションでの TypeScript 導入に知見がある 

なぜ静的型付けで品質があがるのか 参考）拙書『なぜチーム開発において型が好ましいとされるのか』 https://itiskj.hatenablog.com/entry/2019/02/04/102731 > オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング ) で紹介されている静的型付けの導入メリットは、以下の三点です。 ・信頼性 ・可読性 ・生産性 

エラー修正コストと発見タイミング 仕様のエラーが発見された時間とエラー修正 にかかったコストをプロットした Boehm の有 名な研究によれば、発見が遅れれば遅れるほ ど、エラー修正のコストが膨れ上がる 発見タイミング (t) 修正コスト 

Who does “TypeScript”? 

TypeScript 世間の評判 https://insights.stackoverflow.com/survey/2018#most-loved-dreaded-and-wanted 

TypeScript 世間の評判 https://octoverse.github.com/projects#languages 

TypeScript 世間の評判 https://octoverse.github.com/projects#languages 

TypeScript 世間の評判 https://www.bizreach.co.jp/pressroom/pressrelease/2018/0807.html 

How to “TypeScript”? 

TypeScript Compiler の役割 https://github.com/Microsoft/TypeScript/tree/master/src/compiler ・静的型の検査（型違反の検出） ・JavaScript コンパイル時に型定義の除去（実行可能な JS を出力） ・ES6+ から ES5 等のソースコード変換 

型を当てなくても得られるメリット TypeScript Compiler が型違反検出以外に持つ機能 ・未到達リターンの検出（ --noImplicitReturns） ・nullify の検出（--strictNullChecks） ・未使用引数など dead code の検出（--noUnused{Locals|Parameters}） ・ES5 への変換（場合によっては Babel などのトランスパイラが不評） ref. https://www.typescriptlang.org/docs/handbook/compiler-options.html 

型を当てると得られるメリット ・型違反の検出 ・Editor による補完（typescript-language-server） ・可読性の向上による保守性の向上 

TypeScript 導入のデメリット ・学習コスト ・型定義のメンテナンス ・ビルドツールのメンテナンス 

TypeScript 導入のリスク TypeScript のメンテナンスが停止する ・コミュニティ全体で何らかの移行パス・ツールが提供される期待は高い ・TypeScript がコンパイルした結果は「動く JS」 ・最悪の場合、コンパイル結果自体をメンテナンス対象とできる 

どう TypeScript を導入するのか 徐々に型定義を当てていくことで漸進的移行が可能 ・noImplicitAny: false を許容する ・型推論と DefinitelyTyped で提供される型定義でかなりカバーできる ・最悪全て any でも生 JavaScript より圧倒的に品質担保可 ・「がんばらない TypeScript」 

Recommended TypeScript Migration Roadmap 【導入期】まずは TypeScript Compiler を Build Pipeliens に組み込む 【初期開発期】DefinitelyTyped ですぐ利用可能な型情報を組み込む 【漸進的運用期】徐々に独自の型定義を当てていく 【移行完了期】noImplicitAny=false に変更し、他の strict オプションも有効にする 【安定運用期】楽しい TypeScript Life を 

TypeScript の主な機能 ref. https://www.typescriptlang.org/docs/handbook/basic-types.html ・Interfaces ・Generics ・Enums ・Namespaces ・Type Inference その他多数 

Build Pipeline 【静的解析】ESLint でスタイルガイドに沿わないコードを検出する 【ユニットテスト】仕様に沿わないコードを検出する 【コンパイル】TypeScript Compiler で ES5 にコンパイルし、型違反を検出する 【トランスパイル】Babel Transpiler でサポートブラウザ対応を行う 【その他諸々】Webpack で難読化 / Tree Shaking / Chunk Merging / Bundlize を行う 

Babel との使い分け ・サポートブラウザが存在するため ES5 にビルドするだけでは不十分 ・TypeScript は ES5 にビルドし、Babel がサポートブラウザを意識し Polyfills 注入などを担当する 

Lint ・ECMAScript 6+ の書き方をメンバーにも浸透させるため、型定義に加えて静的解析も必要 ・TypeScript チームは TSLint ではなく ESLint をメンテナンスしていく方針にアナウンス（Jan, 2019 ） 　・https://eslint.org/blog/2019/01/future-typescript-eslint ・typescript-eslint のプロジェクトが今後の開発対象 　・https://github.com/typescript-eslint/typescript-eslint ・ルールは ESLint で書き、@typescript-eslint/parser を用いることが今後の標準 　・JavaScript -> TypeScript への移行時も静的解析ツールの移行コストは最低限 

Appendix 

Good References ・mizchi’s blog 『TypeScript入門以前ガイド』 ・角待ちは対空『がんばらないTypeScriptのはじめ方』 

Thank you!