SlackでのJavaScriptからTypeScriptへの移行

SlackでのJavaScriptからTypeScriptへの移行は困難な作業だったが、劇的な改善が見られた、とSlackのディスクトップエンジニアであるFelix Rieseberg氏が書いている。

Slackチームは大規模なJavaScriptのコードベースを管理しやすくするためTypeScriptへの移行を決めた。彼らはJSDocを使ってファンクションのシグネチャや適切な使い方を記述することを諦めていた。Rieseberg氏によれば、特に難しかったのは既存のコードベースに対してJSONを使ってアプローチする方法に従うことだ。コードを変更する時に厳密な原則に従わなければならないが、期待されている型が何なのか知るのはいつも簡単というわけではないのだ。

TypeScriptを選んだ理由の一つはJavaScriptのスーパーセットだからだ。つまり、コードを1行も変更することなく導入でき、徐々にコード分析の機能を有効にして、多くのパッケージで使える型定義を使う。any型を推論することをコンパイラにさせないようにする--noImplicitAnyのような先進的なコンパイルオプションを使うような地点に達した。Rieseberg氏によれば、ディスクトップアプリのコードベースのほとんどのコードベースに注記をつけるのに6ヶ月かかった。このプロセスでは、コンパイラによって多くのバグが見つかり、自動補完のような機能を可能にする編集機能のおかげで開発がスピードアップした。

InfoQは氏にインタビューしこの移行について話を聞いた。

TypeScriptのコンパイラオプションを徐々に有効にするという方針をとったとのことですが、初期の段階でどのオプションを有効にしたのか、既存のコードを修正してから導入する必要があったオプションは何だったのか、詳しく教えてください。

TypeScriptへの移行ではany型が最も強力な引数だと思います。anyを使うことでより具体的な型やインターフェースに徐々に移行することができるからです。型の利用が浸透してくると、遅かれ早かれintersection型とunion型によって提供される抽象を使いたくなってくる人が出てきますが、これは型に慣れていない開発者のやる気をそいでしまいかねません。私の個人的な考えとしてはTypeScriptを徐々に導入するということは既存のJavaScriptの能力を活用することによって実現します。TypeScriptはコードを理解し、開発を可能な限り支援します。まとめて全てのコードベースを移植する時間がなくても役に立つのです。

動的型付け言語から静的型付け言語に移行するのは、場合によっては再設計の機会にも繋がります。Slackではどうでしたか。

TypeScriptへの移行は開発者のOJ Kwonがほとんどをやりました。OJはチームにジョインした後、すぐに移行をはじめました。彼は私たちのコードベースにたくさんの改善点があることにきづきました。特に、TypeScriptへの移行はアーキテクチャ内部のデータの流れを理解する助けになりました。そして、既存のコードを読むことは常に私たちの過去のアプローチを再考することに繋がります。

言語のレベルでは、どの機能が表現力のある型システムを構築するのに役に立ったと思いますか。

特にDeclaration Mergingですね。これによって既存の型と宣言を再利用して私たちが扱っているオブジェクトを表現できます。また、Declaration Mergingほどではないですが、文字列リテラル型も私たちのコードのあらゆるところにあります。

TypeScriptの強みの一つとして、JavaScriptのスーパーセットであることを指摘していましたね。一方、スーパーセットであるが故に、アプリのピュアなJavaScriptのレイヤで何が起こっているのかはわかりません。この点についてはどのように対処していますか。この点は問題になりましたか。

TypeScriptと共にSalsaを使います。Salsaは開発サーバでJavaScriptの開発をTypeScriptライクにするというものです。Visual Studio CodeのJavaScriptのコード解釈に使われています。私たちは、TypeScript、宣言ファイル、Salsaをうまく組み合わせて開発しました。私は個人的にTypeScriptの定義ファイルに対するアプローチを気に入っています。