Node.js、追加設定なしでTypeScriptファイルの実行をサポート
(nodejs.org)- Node.jsがTypeScriptファイルを直接実行できるように改善
- これにより追加設定やトランスパイルなしでも
.tsファイルをそのまま実行可能に - 開発者はtsconfig.jsonや別途バンドラーを導入せずに作業効率を高められる
- この機能は Node.js v22.18.0 (LTS) バージョンから正式に反映
- JavaScriptとTypeScript開発の境界が緩和される結果が期待される
Node.jsのTypeScript直接実行サポート
- Node.jsは最近の v22.18.0 (LTS) バージョンで、TypeScriptファイル(.ts) を別途設定やツールなしで直接実行できる機能を導入
- 従来はTypeScriptコードを実行するために ts-node、esbuild、Babel などの外部トランスパイラまたはバンドラーが必要だったが、今後はこうしたツールなしでも Node.js 自体が TypeScript コードを認識して実行する
- この機能により、開発者はtsconfig.json設定ファイルや追加ライブラリなしで
.tsファイルを Node.js でそのまま実行可能 - プロトタイピング、実験的な開発、スクリプト実行などで生産性と開発のしやすさが大きく向上
- JavaScriptとTypeScriptプロジェクト間の連携性強化、新規開発者の参入障壁緩和などの効果が期待される
そのほか注目すべき変更
- esm:
import.meta.mainを実装 - fs: AsyncIterator ベースの fs イベント処理を改善
- permission: 子プロセス実行時に権限モデルフラグの受け渡しをサポート
- sqlite:
readBigIntsオプションを追加 - src/permission:
permission.has(addon)をサポート - url:
fileURLToPathBufferAPI を追加 - watch:
--watch-kill-signalフラグを追加 - worker:
Workerオブジェクトを async disposable に改善
コミットおよびドキュメント関連アップデート
- 不要なコードの削除、ビルド環境とツールチェーンの整備、npm 10.9.3 へのアップグレードを含む
globals.md,child_process.md,http2などのドキュメントで、安定性指標の詳細や RFC 番号を修正- 多数のテスト追加とバグ修正を反映
配布ファイル
- Windows、macOS(Intel/Apple Silicon)、Linux(x64、ARM、PPC、s390x、AIX) 向けのインストーラーとバイナリを提供
- ソースコードと完全なリリースファイルは Node.js 公式配布ページからダウンロード可能
- API ドキュメントは v22.18.0 基準で更新済み
7件のコメント
本当にすっきりしましたね……早く定着してほしいです
簡単なスクリプトの実行にはよさそうですが、実運用のプロジェクトでは制約が多くて、あまり使う機会はなさそうですね。
ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT エラーのため、拡張子やパスも合わせる必要がありますし、
NestJS のように
"emitDecoratorMetadata"設定による TypeScript ビルド対応が必要な機能は使えないので……--experimental-strip-typesがデフォルトで適用されるということですか？どうせ
enumは使わないので、私の基準では単に型を削除する動作だけでも十分問題なく実行できましたすごく便利になりそうですね！
いいねを我慢できませんね。
--no-experimental-strip-typesフラグでも十分に良いと思っていましたが。さらに良くなったようです。
Hacker Newsの意見
node:testも含めると、いまやほとんどのケースでNode.jsが十分に説得力のあるデフォルトの選択肢になったと思う。tsxで実行できるようになったのは生活の質を大きく上げてくれたが、それでもまだ完全ではなかった。zodやts-rest、trpcのようなツールでエッジでのランタイム型アサーションも主に解決されつつあり、最近はフルスタックTypeScript開発が本当に簡単になった.tsファイルを直接実行でき、しかも十分良い標準テストランナーを内蔵している（--watch対応）。組み込みパッケージも良くなってきている。node:fs/promisesのようなものは、top-level awaitのおかげで非同期ループ処理もずっと簡単になった。みんなを現実的な方向へ説得するには長い時間がかかったが、いまは本当に快適になったvitestが多くの部分を楽にしてくれているが、.tsファイルのテスト環境設定には本当に多くの時間を費やしてきた。trpcとts-restは完全に別の問題だと思う。両方使えるけれど、本番ではtrpcはAPI URLを自分で完全に所有できず、古いURLを自然に管理して廃止していけないので避けている。ts-restについても、たいていはzodと型を直接共有してAPIのリクエスト/レスポンスの組を自分で管理するほうを好む。それにtrpcは明らかにRPCツールなのに、名前に-restが付いているたびに気になるtsxを実行するものなのか気になる。型を取り除いてもJSXはJavaScriptへ変換しなければならないので、その部分がどうなっているのか気になるimport/exportの正式サポートだった（.mjsハックがまだ必要なのかは知らないが）。しばらくエコシステムから離れていたので、その後に何が変わったのか知りたいnode_modulesで受け入れられないのは残念（関連: node.js公式ドキュメント）。 となると、プロジェクト依存関係はどうなるのか気になる。データモデル用ライブラリをTypeScriptで書いたので、TypeScriptのまま自分のアプリにインポートしたい。このルールがnpmパッケージにだけ適用されるのか、それともすべての依存関係に適用されるのか気になる。ここにはチャンスがある。 自分はtypescript（正確にはJS全般）の実行のためのgolangベースのランタイムを作っていて、grafanaチームが使っているsobekも型ストリップ機能を追加するだけでよさそうだ。完全にTypeScriptをデフォルト採用したランタイムが1つでも出てくれば、Node.jsは本当に革新されると感じている。トランスパイラも、typescript-goも、rustも不要で（とはいえrustは少し😉）、良いパーサーがソースマップと型をデバッグモードで追跡してくれる仕組みがあれば十分だ。 いずれにせよNodeチームとすべての貢献者に敬意と感謝を表したい。標準となるNodeがあるおかげで、私たちは皆その後を追える感覚がある。埋め込みAPIもシンプルで使いやすく、スタンドアロンを作るときにも便利だprivateフィールド自体をまったく気にしていないnode_modulesで型ストリップのサポートがないのは残念だと思うnapi関数が未実装で動かず、opendirのオプションでrecursiveが無視される問題など、覚えているものだけでもいくつかあった。Bunが追いつくのを待っている立場だが、まだ大規模プロジェクトへ実務投入する準備ができているようには見えない。bun専用機能も第一印象は良いが、実戦では物足りないと感じる。ドキュメントもNode.jsほど高品質ではないlocalAddressが無視されるEventEmitter関連のrace問題（部分的な解決策: eventemitter2）node_modulesを削除して再インストールする必要があったNode自体のTS機能とテストランナーを使ってみたが、まだBunほど良くはない。しばらくはそうした機能が必要なときにはBunを使っている。Nodeエコシステムでは1つにすべてを賭けるより、それぞれに特化した道具を適切に組み合わせるほうがよいと学んだ。
Bun.js: Nodeランタイム向けで、TS実行とテストに活用。TSX、TS-Node、Node自体などいろいろ試した
NPM: ツーリングスクリプトの実行に使用
PNPM: 依存関係のインストールに使用。（npm、yarn、bunより最も優れていると感じる）
Biome.js: リンティング用。これまで使ったどのリンティングツールよりも優れている
import { stripTypeScriptTypes } from 'node:module'）も公開されている。フロントエンド依存のないシンプルなWebアプリを作るなら、全体をTypeScriptにしてフロントエンドスクリプトを配信するときに型だけ取り除けばよい（サンプルプロジェクト）tscなどの型チェッカーで静的検査を行い、型情報は削除される。Pythonも実行時には型アノテーションを無視するし、Javaでもバイトコードでは一部のジェネリクスなど型情報が消える性質があるtscで回すやり方が自分には合っているtsxを使って、同じくビルドやトランスパイルなしで実行するセットアップをプロジェクトで使っている。開発中には非常に便利だ。tsxの--watchのおかげで、TSソースから直接サーバーを立ち上げ、変更があれば自動で再起動する。今後はnodemonとNode内蔵機能だけで似た環境を作れそうだ。ランタイムで型チェックまでやるならv8レベルでのサポートが必要で、これはほとんど全面書き直し級の作業になるだろうenum以外で、実際に使われる例が何かあるのか知りたい