Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to TypeScript

Introduction to TypeScript

Ken Wagatsuma

March 08, 2019
Tweet

More Decks by Ken Wagatsuma

Other Decks in Programming

Transcript

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

    ・依存ライブラリの取捨選択および最新版へのアップデート ・副作用のある DOM テストの疎結合化および Coverage の向上 ・JSHint -> ESLint や Phantomjs -> Headless Chrome などのツールチェーンの移行
  2. アプリの品質を高めるためのベース  ドメイン知識 (業務フローへの理解 / 知見共有会 / ビジネス目標の浸透) 静的型付け (TypeScript Compiler)

    静的解析 (ESLint) 可読性 (DefinitelyTyped / 独自の型定義) 単体テスト・結合テスト (Karma / Jasmine) デプロイ自動化 ライブラリの 定期アップデート リファクタリング のチーム文化醸成
  3. なぜ社内広告 SDK から導入するのか 課題 前提となるドメイン知識が広く求めれる ・Programmatic Advertising / Header Bidding

    / 社内配信フロー ・したがって、品質担保のみならずコードの可読性も求められる ・JSDoc によるドキュメントの保守性が限界 3rd Party Librariesが多い ・Header Bidding だけでも apstag / googletag / pbjs などの 3rd Party Libraries に依存 ・その他動画広告 SDK や第三者配信タグ
  4. なぜ facebook/flow ではないのか エコシステムの優越性 ・エディター拡張機能などの周辺ツールチェーンが TypeScript より未熟 ・世間的にも TypeScript 導入企業が増えてきて、ユーザーボリュームも

    Flow より多い 持続的開発性 ・Microsoft で開発されている TypeScript の方が安心材料が多い メンバーのスキルメリット ・技術選定者がプロダクションでの TypeScript 導入に知見がある
  5. 型を当てなくても得られるメリット TypeScript Compiler が型違反検出以外に持つ機能 ・未到達リターンの検出( --noImplicitReturns) ・nullify の検出(--strictNullChecks) ・未使用引数など dead

    code の検出(--noUnused{Locals|Parameters}) ・ES5 への変換(場合によっては Babel などのトランスパイラが不評) ref. https://www.typescriptlang.org/docs/handbook/compiler-options.html
  6. Recommended TypeScript Migration Roadmap 【導入期】まずは TypeScript Compiler を Build Pipeliens

    に組み込む 【初期開発期】DefinitelyTyped ですぐ利用可能な型情報を組み込む 【漸進的運用期】徐々に独自の型定義を当てていく 【移行完了期】noImplicitAny=false に変更し、他の strict オプションも有効にする 【安定運用期】楽しい TypeScript Life を
  7. Build Pipeline 【静的解析】ESLint でスタイルガイドに沿わないコードを検出する 【ユニットテスト】仕様に沿わないコードを検出する 【コンパイル】TypeScript Compiler で ES5 にコンパイルし、型違反を検出する

    【トランスパイル】Babel Transpiler でサポートブラウザ対応を行う 【その他諸々】Webpack で難読化 / Tree Shaking / Chunk Merging / Bundlize を行う
  8. 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 への移行時も静的解析ツールの移行コストは最低限