Introduction to TypeScript

Transcript

1. Introduction to TypeScript March, 2019 Kenju Wagatsuma Cookpad Inc.

2. Why “TypeScript”?

3. なぜ TypeScript を導入するのか 目的 ・静的型付けを導入し、アプリの品質を向上させるため ・静的型付けを JavaScript の世界に導入する中で一番妥当な選択肢が、TypeScript 前提 開発基盤やテスト環境は昨年一年間を通して大きく整備してきた、残りのピースが静的型付け

   ・依存ライブラリの取捨選択および最新版へのアップデート ・副作用のある DOM テストの疎結合化および Coverage の向上 ・JSHint -> ESLint や Phantomjs -> Headless Chrome などのツールチェーンの移行

4. アプリの品質を高めるためのベース　 ドメイン知識 （業務フローへの理解 / 知見共有会 / ビジネス目標の浸透） 静的型付け （TypeScript Compiler）

   静的解析 （ESLint） 可読性 （DefinitelyTyped / 独自の型定義） 単体テスト・結合テスト （Karma / Jasmine） デプロイ自動化 ライブラリの 定期アップデート リファクタリング のチーム文化醸成

5. なぜ社内広告 SDK から導入するのか 課題 前提となるドメイン知識が広く求めれる ・Programmatic Advertising / Header Bidding

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

6. なぜ facebook/flow ではないのか エコシステムの優越性 ・エディター拡張機能などの周辺ツールチェーンが TypeScript より未熟 ・世間的にも TypeScript 導入企業が増えてきて、ユーザーボリュームも

   Flow より多い 持続的開発性 ・Microsoft で開発されている TypeScript の方が安心材料が多い メンバーのスキルメリット ・技術選定者がプロダクションでの TypeScript 導入に知見がある

7. なぜ静的型付けで品質があがるのか 参考）拙書『なぜチーム開発において型が好ましいとされるのか』 https://itiskj.hatenablog.com/entry/2019/02/04/102731 > オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング

   ) で紹介されている静的型付けの導入メリットは、以下の三点です。 ・信頼性 ・可読性 ・生産性

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

9. Who does “TypeScript”?

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

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

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

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

14. How to “TypeScript”?

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

    から ES5 等のソースコード変換

16. 型を当てなくても得られるメリット TypeScript Compiler が型違反検出以外に持つ機能 ・未到達リターンの検出（ --noImplicitReturns） ・nullify の検出（--strictNullChecks） ・未使用引数など dead

    code の検出（--noUnused{Locals|Parameters}） ・ES5 への変換（場合によっては Babel などのトランスパイラが不評） ref. https://www.typescriptlang.org/docs/handbook/compiler-options.html

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

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

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

20. どう TypeScript を導入するのか 徐々に型定義を当てていくことで漸進的移行が可能 ・noImplicitAny: false を許容する ・型推論と DefinitelyTyped で提供される型定義でかなりカバーできる

    ・最悪全て any でも生 JavaScript より圧倒的に品質担保可 ・「がんばらない TypeScript」

21. Recommended TypeScript Migration Roadmap 【導入期】まずは TypeScript Compiler を Build Pipeliens

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

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

    その他多数

23. Build Pipeline 【静的解析】ESLint でスタイルガイドに沿わないコードを検出する 【ユニットテスト】仕様に沿わないコードを検出する 【コンパイル】TypeScript Compiler で ES5 にコンパイルし、型違反を検出する

    【トランスパイル】Babel Transpiler でサポートブラウザ対応を行う 【その他諸々】Webpack で難読化 / Tree Shaking / Chunk Merging / Bundlize を行う

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

    Polyfills 注入などを担当する

25. 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 への移行時も静的解析ツールの移行コストは最低限

26. Appendix

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

28. Thank you!