ts-node vs SWC: CIでTypeScriptをより速く実行する
ts-nodeはtscを通じてTypeScriptを実行します。SWC register(または@swc-node)と組み合わせると、Rust速度のトランスパイルに切り替わり、実行がはるかに速くなります。
ts-nodeはTypeScriptコンパイラ経由でTypeScriptを実行します。SWCのアプローチ(ts-nodeの--swcフラグまたは@swc-node/register)はRustのSWCでトランスパイルし、起動をはるかに高速にしますが、実行中の完全なtype-checkingは行わない代償があります。
| ts-node | SWC (register) | |
|---|---|---|
| トランスパイルエンジン | tsc | SWC (Rust) |
| 起動速度 | より遅い | はるかに高速 |
| Type checking | 任意(より遅い) | なし(除去のみ) |
| ESMサポート | 動作する(設定) | 動作する |
| 最適な用途 | 型を意識した実行 | スクリプト/テストの高速実行 |
CIでは
素のts-nodeは実行しながらtype-checkできますが最も遅い選択肢です。SWC register(またはts-node --swc)を使うと同じworkflowを保ちながらはるかに速くトランスパイルでき、スクリプトとテストの起動を削減します。他の高速トランスパイラと同様、SWCはtype-checkしないため、tsc --noEmitを別途実行します。CIでの純粋な実行速度では、SWCの経路が勝ります。
type-checkを分離する
SWCは型を除去するだけなので、型安全のためにtsc --noEmitステップ(並列)を追加します。どちらもmanaged runnerで動作し、高速なmanaged runnerは大きなコードベースでの長いtype-checkパスを短縮します。
The switching cost is mostly in the parts nobody lists
- Assertions and mocks usually port mechanically when the target implements a compatible API; custom transformers and framework plugins do not.
- Snapshot formats differ between runners, so plan to regenerate and review rather than port.
- Run both suites in parallel in CI for a period and diff the results. A migration that changes which tests fail is not a migration, it is a regression you have not found yet.
- Coverage numbers move on a runner change even when the tests do not, because instrumentation differs. Re-baseline any coverage gate deliberately.
結論
TypeScriptの実行を最速にしたいなら: ts-nodeをSWC register(または@swc-node)とともに使い、別途のtsc --noEmitチェックを加える。型を意識した実行を1つのツールで必要とするなら: 素のts-node。ほとんどのpipelineは速度とtype-checkingを分けます。