Skip to content

Instantly share code, notes, and snippets.

@azu
Last active September 22, 2024 09:48
Show Gist options
  • Save azu/ac5dafbf211ef8b5ecf386930ac75250 to your computer and use it in GitHub Desktop.
Save azu/ac5dafbf211ef8b5ecf386930ac75250 to your computer and use it in GitHub Desktop.
Node.jsのTypeScriptサポートについて

Node.jsのTypeScriptサポートについて

  • Created: 2024-07-28

Node.jsのTypeScriptサポートに関する議論を時系列でまとめたものです。

Start

SWCを使ってTypeScriptの型を削除することで、Node.jsのTypeScriptサポートを実現するという提案からスタートした。

最初の懸念としては、Node.jsのLTSは3年保守する必要があるので、依存によってNode.jsのLTSサポートが難しくなるという話。 具体的には次のような懸念があった

  • SWCがSemverではないこと
  • TypeScriptがSemverではないこと

SWCについては、kdy1(SWC Author)からNode.jsが使うならそれ用のパイプラインを作るという話をした。

Node.js Loaders Team Meetingで、Node.jsにTypeScriptのサポートを入れたいという合意自体はある程度できた。 実際にtype stripでそれが実現できるかは実験する必要があり、undiciの例にならって外部のパッケージとして進めることでコアのリリースサイクルの外で進めることが提案された。

@swc/wasm-typescript

SWCにTypeScriptの型を削除するWasmパッケージが追加された。

この時点では次のような変換をしていた。

- const foo: string = "foo";
+ const foo = "foo";

ts-blank-space

TypeScriptの型を取り除いてJavaScriptへ変換するブルームバーグ社内での実験についての知見が共有された。

次のような空白の位置を維持しながら型を削除することで、Source Mapを不要にしつつ行番号を維持できるという話が共有された。 Source Mapの対応をしないことで、TypeScript to JavaScriptの変換が単純になりパフォーマンスを良くできるという話があった。

- const foo: string = "foo";
+ const foo         = "foo";

これを受けて、 @swc/wasm-typescriptstrip-only もこの対応をしている。

SWCのPlaygroundにも strip-only が追加された。

TypeScript Teamとの議論

問題として"TypeScriptのサポート"といったときに、型を取り除くだけで実現できない機能があるため、TypeScriptのサポートとは言えないという話がある。 具体的には、enumnamespace、decoratorなど、TypeScriptが型だけではなくコードとして出力する例外的な機能もすでに存在している。 これらのコードを出力する機能が今後増えると、Node.jsのLTSは守れなくなる問題が存在している。

またTypeScriptチームからも"TypeScriptサポート"といった場合のユーザーがどう思うかについての懸念があった。

これについてNode.jsのLoaders TeamとTypeScript Teamの間で議論が行われた。

議論結果は次のコメントにまとめられている。

TypeScriptチームとしては、"TypeScriptサポート"といった場合には、enumnamespaceも含めたものを想定している。 一方で、このようなJavaScriptのコードを出力する機能(型を取り除くだけで実現できない機能)を増やす可能性はかなり低いという話もされた。

また、Node.jsがTypeSriptサポートをした場合に、.tsをnpmのregistryにpublishすることについての懸念と議論も行われた。 課題は色々あるが、ひとまずはNode.jsがTypeScriptサポートについてのIterationを進めること自体のブロッカーはないという結論になった。

そのあともNode TSCで議論が行われて、Node.jsのユーザー体験に関わる部分なのでNode.js Loaders Teamだけではなくもっと広い範囲で話したほうが良いかもしれないという話がされた。 また、node_modules/に対して現状の実装では適応するべきじゃないことやNode.jsとTypeScript Teamのコラボレーションをどうやってやるかなどについても議論された。

module: add --experimental-strip-types #53725

@swc/wasm-typescriptをラップしたAmaroというモジュールをNode.jsに追加するPRがマージされた。 次のような実験的なフラグを使って、TypeScriptのコードから型を取り除いたJavaScriptとして実行できるようになった。

node --experimental-strip-types main.ts

Roadmap for experimental TypeScript support #217

Node.jsのTypeScriptサポートについてのロードマップは次のIssueで議論されている。

まだenumnamespaceなどをどうするか、拡張子がないファイルのimportの対応、node_modules/以下のファイルの.tsは扱うべきなのか(npmにpublishされたものをどうするかという話)、@swc/wasm-typescriptを使って実現しているがパフォーマンスを考えるとネイティブに実装するかなどの論点が残っている。

Node.js CoreでのTypeScriptサポートについて議論するリポジトリが作られた

--experimental-transform-typesフラグを元にenumnamespaceの変換をサポートした。

Node.jsのTypeScriptサポートは限定的で、tsconfig.jsonでそのNoe.jsのTypeScriptサポートに対応するオプションをまとめて有効化したいというIssue

@fushihara
Copy link

2022年頃からtc39側でも Type Annotationsという名前で、
「Typescriptをフルサポートするのはしんどいけど、型部分を無視する機能だけ先にどう?」って提案されている事を思い出した。
https://github.com/tc39/proposal-type-annotations

typescript側がenumやnamespaceなどJavascirptコードを出力する機能と、エディタ上で型ヒント・エラーを出すだけの機能を分離してくれるのが一番手っ取り早そうだが・・・

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment