2026年7月9日(木)掲載 2,468本日 45
HN436168

TypeScript 7は来るのか?次期バージョンの噂と展望を徹底考察

TypeScript 7

DanRosenwasser約17時間前

議論

11
0DanRosenwasserスレ主436約17時間前

現在、TypeScriptのバージョン動向についてコミュニティで注目が集まっています。特に「TypeScript 7」のリリース時期や、それに伴う破壊的変更、期待される新機能について考察します。現状、公式からの具体的なロードマップはまだ公開されていませんが、TypeScriptの進化のスピードを考えると、さらなる型安全性とコンパイルパフォーマンスの向上が鍵になるでしょう。今後の情報公開が待ち遠しいですね!

1dimitropoulos約17時間前

ここでの真のストーリーは、人類史上最も高度な型システム(ヒンドリー・ミルナーなんて目じゃないね)のために、2つの別々のコードベースを同時に維持し続けた信じられないようなチームの存在だよ。チームのみんな、本当におめでとう!Rustでの書き直しを楽しみにしているよ ;)

2adamddev1約15時間前

「型なんて手間がかかるだけで無駄」って議論してた頃が懐かしいね。TypeScriptのおかげで型が普及したってだけでも、TypeScriptを愛さずにはいられないよ。

3chroma_zone約15時間前

JSDocの型構文に引き続き焦点が当たっているのは嬉しいな。自分のプロジェクトでTypeScriptを使うのに一番気に入ってる方法なんだ。構文の一部に変更があって修正が面倒な部分もあるけど、全体的には良くなってるみたいだね。

4skybrian約15時間前

TypeScriptのコンパイラAPIはまだないけど、取り組んでいるという話を聞けて勇気づけられたよ。

5miiiiiike約15時間前

数年TypeScriptを使っていると、Pythonで型アノテーションを使ったり、基本的な言語機能をabcみたいにインポートしたりするのが、とんでもなく面倒な作業に感じられてしまうな。

6Exoristos約15時間前

メモリ消費が減ってパフォーマンスがこれだけ劇的に向上するグラフを見ていると、なぜ自分はサーバーサイドでGoじゃなくてTypeScriptを使っているんだろうって疑問に思えてくるね。

7m3h約14時間前

テスト結果に基づく高速化の数値はこんな感じ:

    コードベース    | TypeScript 6 | TypeScript 7 | 高速化
    ------------|--------------|--------------|--------
    vscode      | 125.7s       | 10.6s        | 11.9x
    sentry      | 139.8s       | 15.7s        | 8.9x
    bluesky     | 24.3s        | 2.8s         | 8.7x
    playwright  | 12.8s        | 1.47s        | 8.7x
    tldraw      | 11.2s        | 1.46s        | 7.7x

(Bunとは違って)責任ある移行をしつつ、この偉業を成し遂げたチームに拍手を送るよ。
一つ質問なんだけど、tsdownやesbuildみたいにTypeScriptのコードベースをビルドする必要があるダウンストリームツールにはどう影響するのかな?TS 7と今のtsdownを一緒に使えるんだろうか?

8dzonga約13時間前

TypeScriptチーム、おめでとう。

もっと長いブログや音声で投稿したいところだけど、手短に言うと、JavaScript/TypeScriptのエコシステムは木工に似ているんだ。

安っぽい合板のIKEA家具みたいなものも作れる。コードで言えばオリジナリティのない「なんとなく作ったアプリ」だね。

一方でハイエンドなものなら、精巧な家具や木造の高層ビルみたいに、若い木材を重ねて耐火性の梁を作るような高度な接合や積層技術を使うこともできる。JavaScript/TypeScriptのエコシステムでも、強力な工作機械のようにAIを駆使しつつ、クラフトマンシップを持ってハイエンドなものを作れるんだ。

作る勇気がある人、挑戦する勇気がある人は、ぜひTypeScript/JavaScriptのエコシステムを存分に活用してほしい。

9mckee_plus_plus約11時間前

TypeScriptの大きな悩みどころは、プロジェクトの一部に対してtsconfigの設定やライブラリ・型をスコープ分けすることだね。

自分のプロジェクトはWebアプリだけど、vite.config.tsやPlaywright、ユニットテストのせいでIDEのツールチェーンにはNodeの型が入ってしまっている。だから、ReactコンポーネントにNodeのAPIを足しても、tscは警告してくれないんだ。

今のところDOMライブラリとNodeライブラリを分離するには、プロジェクト参照(Project References)というスパゲッティコード状態で、大量のtsconfig.jsonやtsbuildinfo出力ファイルが必要になるし、プロジェクト参照で型を出力しないようにするのも面倒で仕方ない。

10austin-cheney約10時間前

興味深いね。でも、NodeがネイティブでTypeScriptの型アノテーションを削除(strip)してくれるようになったから、最近はめったにTSCを動かさないな。本当に使うのは、大きな退行バグを入れてしまって、更新できていない箇所を確認するためにコンパイラから静的な出力を得る必要があるときくらいだね。

ブラウザ向けのフロントエンドコードでさえ、Nodeの型削除に頼り切っているよ。