BloombergのJavaScriptインフラストラクチャおよびツールリードであるRob Palmer氏は、先頃、BloombergでのTypeScriptの大規模な採用から得られたいくつかの学習ポイントと洞察を共有した。Bloombergのカスタムランタイムに固有の学習ポイントもあれば、TypeScriptに切り替える大規模なコードベース全体で役立つ学習ポイントもある。
Palmer氏は、Bloombergは既存のJavaScriptコードベースの規模が大きいため、慎重なプロセスに従ってTypeScriptに移行したと説明した。Bloombergターミナルには、10,000を超えるアプリケーションが含まれている。BloombergのJavaScriptコードベースには、5,000万行を超えるコードがある。2,000人のソフトウェアエンジニアがJavaScriptを書いている。
Bloombergには、V8エンジンとChromium上に構築された独自のJavaScriptランタイム環境とプラットフォームがある。Bloombergのカスタムランタイムは、TypeScriptを直接サポートしている。Bloombergの開発者に標準化された合理化されたエクスペリエンスを提供するよう努めている。Palmer氏は詳しく説明した:
当社のプラットフォームは、共通のツールおよびパブリッシングシステムを使用するパッケージの内部エコシステムをサポートしています。これにより、TypeScriptの「厳密モード」をデフォルトにするなどのベストプラクティスを奨励および実施したり、グローバルな不変条件を確保したりできます。たとえば、公開されているすべてのタイプがグローバルではなくモジュールであることを保証します。また、エンジニアは、TypeScriptをバンドラーやテストフレームワークでうまく機能させる方法を理解する必要がなく、コードの記述に集中できることも意味します。DevToolsとエラースタックはソースマップを正しく使用します。テストはTypeScriptで記述でき、コードカバレッジは元のTypeScriptコードで正確に表現されます。それはうまくいきます。
移行プロセスでは、標準 (ECMAScriptなど) に準拠し、TypeScriptコードベースが大きくなっても開発の生産性を高く保ち、パッケージが効率的に連携するようにした。Palmer氏は、時間の経過とともに蓄積された10の学習ポイントを共有した。それらのいくつかは、TypeScriptに移行するすべてのコードベースに適用される可能性がある。その他は、Bloombergの特定のTypeScript採用戦略に関連している。
一般的に適用可能な学習ポイントの1つは、将来のJavaScript機能と矛盾しないTypeScript仕様の部分を使用し、入力情報の追加に焦点を当てることである。標準のECMAScript構文およびランタイムセマンティクスとの整合性は、JavaScriptのタイプレベルの拡張ではないTypeScript言語機能 (enum、namespace、パラメータプロパティやTypeScriptデコレータ) を回避する必要があることを意味する。TypeScriptデコレータのセマンティクスは、たとえばJavaScriptクラスフィールドの提案と互換性がない (ステージ3、つまりJavaScript言語標準での採用が近づいている)。MobX状態管理ライブラリは最近、新しいJavaScriptデコレータの提案 (ステージ2) に合わせた新しいバージョンをリリースした。
2つ目のポイントとして、Palmer氏は、TypeScriptコンパイラの最新バージョンに定期的にアップグレードすることを推奨した。理想的には、単一のTypeScriptバージョンをコードベース全体で使用する必要がある。ここでの理論的根拠は、一般的に新しいTypeScriptリリースと一致することで、タイピング、安定性、および速度の改善から利益を得ることにある。ただし、新しいTypeScriptバージョンでは、以前は検出されなかったタイプのエラーが発生するため、ビルドプロセスが中断する可能性がある。互換性の問題は型定義ファイルでも発生する可能性があり、その一部には古いバージョンのTypeScriptでは理解できない新しい構文が含まれている可能性がある。BloombergのCI統合、共通ツール、およびTypeScriptプロジェクトの集中レジストリにより、TypeScriptのベータリリースおよびリリース候補 (RC) リリースをコードベースで事前にテストできる。したがって、問題はコンパイラのアップグレード前に修正できる。
3番目の一般的な学習ポイントは、コードベース全体で一貫した tsconfig 設定を使用することである。ここでも、すべてのプロジェクトに適用される単一の構成を設定することにより、エコシステムの一貫性を確保することが目標である。パッケージ間の競合がないことで、カスタマイズの柔軟性が低下する。
Palmer氏が言及したもう1つの一般的に適用可能な学習ポイントには、常に1つのバージョンのタイプのみが存在することを確認することが含まれる。Palmer氏は言った:
プロジェクトの特定のコンパイルで、タイプチェックがパッケージの依存関係の単一バージョンのみを考慮することを保証するために、[…] タイプに「正確に1つの」保証を提供したかったのです。コンパイル時の効率に加えて、[…] 私たちは特に、古さの問題と、互換性のない2つのバージョンのnominalタイプが「ダイアモンドパターン」を介してインポートされる「nominal地獄」を避けたかったのです。これは、nominalタイプのエコシステムの採用が増えるにつれて大きくなる可能性が高く危険です。
同様の一貫性の理由から、暗黙的な型の依存関係は避ける必要がある。このような型の依存関係は、グローバル型への依存によって引き起こされる可能性がある。TypeScriptのドキュメントでは、グローバル変更モジュールの使用は、実行時の競合の可能性があるため、やや危険なパターンであると説明されている。
Palmer氏は、手動で書き込むのではなく、.ts ソースファイルから .d.ts タイプファイルを自動生成するというBloombergの特定の決定に大きく起因する追加の学習ポイントについて言及した。この戦略では、ソースファイルを信頼できる唯一の情報源として保持することで、手動のタイプファイル書き込みプロセスの特徴的な同期の問題を回避する。一方、この戦略は、Bloombergが時間をかけて取り組むことを学んだ一貫性とスケーラビリティの問題を生み出す。
Palmer氏のブログ投稿は、豊富な例と技術的な詳細、Bloombergの経験に完全に関連しています。Palmer氏は、発生した問題と、それらがどのように軽減または解決されたかについて説明する。追加の詳細に関心のある開発者は、オンラインで投稿を確認できる。
Palmer氏は、移行の取り組みがBloombergの開発者に好評であると明らかにした:
エンジニアは自発的に変換を開始し、プロセスを支持していました! TypeScriptプラットフォームサポートのベータ版をリリースしたとき、最初の1年だけで200を超えるプロジェクトがTypeScriptを選択しました。ゼロプロジェクトが戻ってきました。
TypeScriptの採用が拡大し続けるにつれて、技術リーダは大企業で採用されている移行戦略、プロセス、およびツールから学ぶことができる。Airbnbエンジニアリングチームは、JavaScriptコードをTypeScriptに移行するのを助けるツールである ts-migrate を最近リリースした。チームは昨年、JSConf HawaiiでTypeScriptの採用プロセスを発表した。