はじめに
Svelte の開発者 Rich Harris さんの Twitter にて、SvelteKit は JavaScript で書かれているという話が話題になっていました。
Svelte は TypeScript から切り替えていますか？これは間違いですよね？
https://thenewstack.io/rich-harris-talks-sveltekit-and-whats-next-for-svelte/
いや、この記事は正しい。SvelteKitはJSで書かれ、ソースコードとして配布され、ビルドステップはなく、生産性に奇跡的な効果をもたらしています。
じゃあ無理して TypeScript を使わなくても JSDoc で代用できるってこと？
と思ったら勘違いでした。
※2023/4/6 追記：こちらの Dev Vlog でも言及されていました。
TL;DR
- 製品コードは TypeScript で書かないほうが都合が良い場合がある。
- でも、TypeScript の型定義は使いたい。
- だから、JavaScript + JSDoc、必要であれば .d.ts ファイルで型定義。
TypeScript で書かないことによる利点
トランスパイルせずにテストを実行できる。コードスニペットをdevtools/node REPLにコピーペーストすれば、そのまま動作する。
確かに！コピーしたコードから型情報を削除する手間を省けますね。
バグを修正する場合、reproをクローンしてパッケージをリンクし、修正されるまでrepro/node_modules/@sveltejs/kitの中でソースコードを直接編集し、修正したものを直接コミットすればいいのです。
私は SvelteKit の開発者ではないのでよくわからなかったけれど、node_modules 内のソースコードを修正してそのままコミットする、ということが開発効率アップにつながってるみたいですね。
TypeScript による型チェックの利点を捨てる必要はない
私は同意しているわけではありません。例えば私のIDBライブラリはLOCの観点でほとんどが型であり、それらの型をエクスポートできることは便利であり（JSDocでそれができるか）、それらの型のためのテストを書くことは問題を捕らえた https://github.com/jakearchibald/idb/blob/main/src/entry.ts
ただ、JSDocのタイピングが過小評価されていることには同意します。
.d.tsファイルにインターフェイスなどを記述し、tscでエクスポートされた関数などの型を生成することができます（example config https://github.com/Rich-Harris/devalue/blob/master/tsconfig.json#L5-L7 )。SvelteKitには、その型に対するテストがあります。
失うものは何もない、鎖だけだ！
.d.ts ファイルであれば製品コードとは関係なく TypeScript の機能をフルに利用できますね。
私が思う TypeScript の嫌いなところ
私が TypeScript の素人だからかもしれませんが、型情報が複雑に混在しているせいで、肝心のビジネスロジックが読みづらく感じています。まぁ、これは私の能力の問題の可能性が高いですが...。
いずれにせよ、JavaScript + JSDoc + .d.ts パターンであれば、この点も解消できます。
まとめ
JSDoc は製品コードをトランスパイルせずに出荷できるにもかかわらず型チェックも可能な仕組み、と捉えればその利点を理解できました。また、TypeScript と対立するものではなく .d.ts ファイルを使用することで共存できることも理解できました。
そして、TypeScript vs JSDoc という対立は存在しないこと。あるとすれば、製品コードファイルにおける .ts vs .js であると理解しました。
今後は、検証の意味も込めて、JavaScript + JSDoc + .d.ts パターンで実装してみようと思います。