86
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

TypeScriptのネイティブ版をさっそく導入したらCIが止まりました

86
Last updated at Posted at 2025-12-03

皆さんこんにちは。この記事は株式会社カオナビ Advent Calendar 2025の4日目(シーズン3)の記事です。

TypeScriptに関連する最近のニュースとしては、TypeScriptチームからネイティブ版(Go移植版)の現在のステータスが共有されましたね。

まだ実装中の機能もありますが、型チェックに関してはかなり安定したステータスになっているとされています(上記の記事から引用、強調は筆者)。

A frequent question we get is whether it’s “safe” to use TypeScript 7 to validate a build; in other words, does it reliably find the same errors that TypeScript 5.9 does?

The answer is a resounding yes. TypeScript 7’s type-checking is very nearly complete. For context, we have around 20,000 compiler test cases, of which about 6,000 produce at least one error in TypeScript 6.0. In all but 74 cases, TypeScript 7 also produces at least one error. Of those remaining 74 cases, all are known incomplete work (e.g. regular expression syntax checking or isolatedDeclarations errors) or are related to known intentional changes (deprecations, default settings changes, etc.). You can confidently use TypeScript 7 today to type-check your project for errors.

現在はプレビュー版のため @typescript/native-preview をインストールして使うことになりますが、弊社カオナビにTypeScriptのネイティブ版を導入するべき時が来たと判断してさっそく検証してみました。

インストールは簡単で、npmを使っている場合はこんな感じですね。

npm i -D @typescript/native-preview

そして、tscを用いていたスクリプトをtsgoに置き換えるだけです。

-tsc --noEmit
+tsgo --noEmit

手元での型チェック所要時間

前々から公式に説明されてきたことですが、もちろんプロジェクトによるものの、ネイティブ版にすることで10倍程度の型チェック高速化が見込めます。

Just as a reminder, even without --incremental, TypeScript 7 often sees close to a 10x speedup over the 6.0 compiler on full builds!

カオナビのコードベースの型チェック時間については、前の記事でも紹介したとおり、手元の開発環境では55〜56秒くらいでした。

これを tsgo で置き換えるとこのようになりました。

yarn tsgo --noEmit  46.54s user 8.49s system 379% cpu 14.508 total

実行時間は14.5秒となり、3〜4倍程度の高速化を達成できています。また、CPUを3〜4コア使用できていることが分かりますね。10倍とはなりませんでしたが、Goへ移植したことによる並列化の恩恵を受けられていることが分かります。

CIに導入してみた

ということで、CI上で実行している型チェックをさっそくtsgoにしてみました。

その結果、CIの実行時間も短縮されました。めでたしめでたし :sleeping_accommodation:

となれば良かったのですが、残念ながらそうはなりません。tsgoの実行が終わらず、1時間後にCIがタイムアウトするまで終わらないという結果になってしまいました。

ジョブのログにも何も情報はありません。

結論から述べると、tsgoにしたことでメモリ使用量が増加し、メモリ不足に陥っていたことがCIが終わらない原因であることが分かりました。CI用のジョブランナーのメモリは8GBでしたが、16GBにすることでtsgoの実行が完了するようになりました。ちなみに、メモリ使用量は増えましたが実行時間は3〜4倍程度の短縮が見られました。

Goへの移植により一般にはメモリ使用量が削減されるはずというのが公式の説明なので、これは意外な結果でした。

意外な結果だと思いましたが、よく考えたらメモリ効率が良くなったと言っても並列度が増しているので、瞬間的なメモリ使用量が増加するのは自然なことですね。普通にCIのメモリを増強するのがよさそうです。

残念ながら、具体的にどれくらいメモリ使用量が増加したのかといったデータは出せません。(隠したいというより調査してデータを出すのが大変なので)

うちもメモリ使用量が増加したという会社の方がいたらぜひ知見を共有してくださると幸いです。

ちなみに、筆者はCIでメモリが足りなくなったらログも出さずに固まるという事象を以前も経験したことがありました。最初どうして固まってしまうのかパッと思いつかなかったのですが、これは以前の経験からすぐに思いつくべきでしたね。

余談: VS Code拡張機能

公式の記事では、VS Codeの拡張機能もネイティブ版が出ているので、こちらも試してほしいとのことでした。

筆者が試してみたところ、実際に以前よりもロード時間が短縮され、パフォーマンスが良くなっているのが感じられます。

まとめ

ということで、TypeScriptのネイティブ版を早速導入してみたというご報告と、その際に若干詰まった点の共有でした。

CIや開発者体験に好影響を与えてくれるのは間違いありませんので、プレビュー版というステータスではありますが臆せず導入していこうと思います。

86
16
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
86
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?