この動画では、開発者がTypeScriptの性能問題、特にTRPCのような型推論を多用するライブラリでの問題を解決するために4000ドルを投資した経験を紹介している。TypeScript言語サーバーの頻繁なクラッシュや型チェックの遅延に悩まされた著者が、TRPCの作者Alexと共に専門家Davidに調査を依頼した結果、TypeScript自体のキャッシュ機能に問題が発見され、TypeScript 5.9ベータで大幅な性能改善が実現されたという開発者向けの技術解説である。
TypeScriptの性能問題と解決への投資
皆さんに正直に言わなければなりません。TypeScriptを愛している一方で、確実に問題があることも事実です。特に性能の面でです。いえ、ランタイム性能の話ではありません。nodeやbunなど、どのような方法で実行するかの話ではないのです。私が特に言及しているのはTypeScriptの性能、つまりTypeScript言語サーバーやLSPの性能のことです。
現在Golangでの書き直しが進行中で、私はそれにとても期待しています。しかし、私や他の人々が現在対処している問題があり、これらは確実に修正可能なはずです。ZodやTRPCのようなツールを使用する大規模なコードベースで作業していると、問題が発生するたびにコマンド+シフト+Pを押して「res」と入力し、エンターを押してTypeScriptサーバーを再起動することが習慣になってしまいました。すべての型を推論するために行う大量の推論処理により、サーバーがクラッシュしたり、遅れたり、単純に問題を起こしたりする可能性が非常に高いからです。
TypeScriptに大きく投資したことで、ほとんど罰を受けているような気分になることもありました。この問題は解決可能に思えましたし、私と他の数人は本当にこれを解決したいと思っていました。TRPCの作者であるAlexと私は、口先だけでなく実際に行動に移し、この問題を一度で解決しようと決めました。
専門家による調査の開始
私たちはTypeScriptサーバー性能の業界専門家に連絡を取り、TRPCの監査を行って何が問題なのかを把握しようとしました。その調査の結果は、私が決して予想できなかったものでした。TypeScript自体に大きな変更がマージされ、現在TypeScriptベータ版で誰でも使用できるようになったのです。
これは本当にワイルドな旅でした。そして私が今まで使った中で最高の投資の一つです。私の少しの時間と現金が、このようなクールなものに貢献できたことに心から感謝しています。これについて詳しく説明するのが待ちきれません。TypeScript 5.9ベータで変更されている他のクールなことについても触れていきます。しかし、これらは私にお金をもたらすものではありません。実際、お金がかかりました。それでは、今日のスポンサーからの簡単なメッセージの後、すぐに本題に入ります。
セキュリティの重要性とスポンサー紹介
あなたのアプリは本当に安全ですか？もしイエスと答えたなら、どの程度確信がありますか？私がリクエストでスパムできるでしょうか？AI生成エンドポイントがある場合、私がそれを大量に叩いて大金を費やさせることができるでしょうか？セキュリティは今まで以上に重要です。特に、リクエストが数セントではなく数ドルかかる可能性のあるAIアプリを構築している場合は特にです。私はT3 Chatでこの問題に直面し、皆さんにも同じ目に遭ってほしくありません。
だからこそ今日のスポンサーが私にとって非常にエキサイティングなのです。実際、私はArcJetの初期投資家でした。彼らが今日持っているものを構築するのに時間がかかりましたが、今彼らが私のスポンサーになって、皆さんに詳しく説明できることをとても嬉しく思っています。彼らは本当にセキュリティと開発者、そして開発者体験を理解しています。
私が見た他のプラットフォームは、コードから非常に離れた場所にあるダッシュボードと設定の束でした。だからこそ、私は実際にそれらを使用することはありませんでした。キャプチャのようなものでさえ、ソースの一部というよりもダッシュボード設定になる傾向があります。これは私を狂わせました。T3 Chatを開始したときにArcJetが準備できていればよかったのにと思います。なぜなら、今私たちが行っていることに完璧だからです。
彼らは使いたいと思うほぼすべてのWebフレームワークをサポートしています。バニラNode.js、bunや、Next.js、SvelteKit、さらにはNest.jsのようなより深いものまで。信じられないかもしれませんが、すべてサポートされています。NestでエンタープライズでもNextでスモールスタートアップでも問題ありません。一般的な攻撃から保護する汎用シールドを設定できます。しかし、はるかにエキサイティングなのは、レート制限コードのようなこれらのセクションです。これは本当に素晴らしいです。
キーを入力し、レート制限の識別子として使用したい特性を選択します。その後、どのくらいの頻度で補充されるか、どのくらい補充されるかなどのルールを持つトークンバケットを作成します。これはすべてコード内で行われます。特別なことをする必要はありません。ネットワークにアクセスするので遅くなると思うかもしれませんが、そうではありません。
内部的にWASMバインディングを持っており、リクエストを検証できます。何らかの理由でまだ確信が持てない場合にのみ、サービスに確認を求めるため、非常に高速で安価、そして信頼性が高くなります。ボット保護は素晴らしいです。ユーザーがLLMで何かを生成できるエンドポイントがある場合、ボットがそのエンドポイントを叩いて大量のものを生成できるようにしたくありません。とんでもない金額がかかります。私の言葉を信じてください。私たちは経験しました。
ホームページ全体がソースコードの例であるセキュリティ製品を見たことがありますか？AIについて言えば、トークン化された補充レートの実行方法に関する完全なガイドとブループリントがあります。ユーザーが特定の期間内に生成するトークン数が多すぎないようにしたい場合、それもカバーされています。これらの企業がこれに特に焦点を当てているのを見たことがありません。
私自身が移行を検討するかもしれません。soyv.link/arcjetで今すぐアプリを保護してください。
問題解決への取り組み
最初から説明すると、これはすべてが始まったグループチャットです。AlexがDavidを十分よく知っているかどうか、この紹介ができるかどうか尋ねてきました。私は知っていましたし、この機会にとても興奮していました。
そこで、クレイジーにネストされたTRPCルーターの性能問題を潜在的に修正するために何ができるかについて、全員で話し始めることができるグループチャットを作成しました。まず馴染みのない方のために、TRPCについていくつかのコンテキストを提供すべきでしょう。これはTypeScriptでバックエンドとフロントエンドを一緒に行う最良の方法です。
バックエンドとフロントエンドがTSでTRPCを使用していない場合、私はあなたの意思決定プロセスに疑問を感じています。なぜなら、それは人生をはるかに良くするからです。これはConvexの大きなインスピレーションの一つでもあります。本当に良いバックエンドとフロントエンドのリンクを持つというコンセプトがどこから来たのか興味があるなら、TRPCがそれらの多くの発明者でした。
もともとはZodを作った人によってデモとして作成されました。Colin、Alexが引き継ぎ、プロジェクトを大きく推進しました。これは私が構築し、より強力に推進したT3スタックの中核でもありました。それ以来、T3スタックはより多くのモジュラーで汎用的な用語になり、構築のさまざまな方法を指すようになり、TRPC自体も大きく進歩しました。
TRPCの動作原理と性能問題
しかし、なぜこれが性能問題を抱えるのでしょうか？まず、それが何をするのか、そしてそれがどれほどうまく機能するのかを見てみましょう。私たちのコードベースでランダムなTRPC関数を取得し、それをどのように使用するかを見てみます。ここに私のuseUserInfoフックがあります。これはT3 Chatでユーザー情報を追跡するフックです。このフックは、T3 Chatのアカウントの名前、メール、その他すべての詳細を提供します。
useQueryコールがあります。これはちなみにTanStack React Queryです。従来のReact Queryです。このクエリオプションヘルパーを渡します。これは私が本当に気に入っているTRPCの新しい方法です。tRPC.getCurrentUserInfo.queryOptionsでuseQueryを呼び出します。
これにより、React Queryが取得、キャッシュ、管理、その他必要なことを行うために必要なすべてのものが提供されます。これはフロントエンドコードです。明らかに、これはこのものを使用するReactフックです。コマンドクリックすると何が起こるか見てください。バックエンドで定義されているプロシージャに移動します。これより素晴らしいことがあるでしょうか。バックエンドとフロントエンドコードが完全に型安全であることを。
そして、このフックを他の場所で使用している場合、どこで使用しているか見てみましょう。ここでアカウントに関する情報を表示するために使用しています。data.tierでisProをチェックしています。data.tierを含めずに、これをコメントアウトしたとしましょう。まだ保存していないことに注意してください。ファイルは未保存ですが、それでもここで型エラーが発生しています。これは真のバックエンドからフロントエンドへの型安全性があるからです。コード生成はありません。
通常対処しなければならない特別なトリックや隠されたものもありません。現在、コードベースを開発で実行していません。コードを変更したばかりで、完全なスタック型安全性があり、すべてが推論された型で消費されているため、ちなみに、これらの型をどこでも定義する必要はありません。
これにより、このカスタムフックのようなパススルーレイヤーがエラーが発生する場所ではない、本当に良いフルスタック体験が得られます。なぜなら、エラーが発生すべき場所ではないからです。データを消費している場所で発生すべきです。これにより、バグを検出し、実際に影響を与える場所を特定することがはるかに簡単になります。AIがいつ良い変更や悪い変更を行っているかを知るために、このタイプのフィードバックが必要な新しいAI時代では、これは命綱です。
私はTRPCに非常に興奮しており、適切な型安全クエリロジックとミューテーションを使用してバックエンドとフロントエンドを接続することがいかに簡単かということに興奮しています。その中核となる構成要素はプロシージャです。これはエンドポイントのようなものですが、それ以上のことができます。例えば、認証された場合にのみ機能するプライベートプロシージャであるカスタムプロシージャを作成できます。
アカウントサービスルーターに行くと、それらはすべて保護されたプロシージャです。なぜなら、それらが機能するためにはサインインする必要があるからです。したがって、このプロシージャはオフでない場合は失敗します。コードが実行される時点で、ユーザーがオフである必要があることがわかります。なぜ今これをすべて持ち出しているのでしょうか？TRPCがTypeScriptを深く使用する方法を示すために簡単な概要を提供したかったのです。
TRPCルーターの構造と型推論の複雑さ
これはT3 ChatのTRPCルーターです。これをGraphQLスキーマのように考えることができます。ここには、クライアントでクエリできるすべてのものがあります。ここでget current user infoやget rate limit dataのように、ルーターに直接クエリを配置できます。しかし、課金が独自のルーターにセグメント化されているような特定のもののためのサブルーターがあります。
アカウントサービスはオフであり、古いデータ取得のための従来のルーターです。これらのルーターは、より組み合わせ可能で分離・分割しやすくするために、独自のボックスで定義されたエンドポイントのコレクションです。しかし、これを行うかどうか、どのように行うかはあなたの選択です。しかし、人々が多くのサブルーターを持つルーターを持つことは非常に一般的です。
これらのサブルーターはそれぞれ同じ方法で定義されます。プロシージャを作成し、入力を与え、ミューテーションを与えます。これらすべては、billing routerを使用するときに、get billing portalという名前の保護されたプロシージャがあり、入力タイプがinputを通じて推論され、戻りタイプがミューテーション関数の戻り値に基づいて推論される、下から上への型推論です。
チェーンを上っていく多くの推論を行う必要があります。optionsが何であるかを把握するために入力を推論する必要があります。get billing portalが何を返すかを把握するために戻りタイプを推論する必要があります。ここの他のすべての値についてもこれを推論する必要があります。そして、ここにダンプするときも、型定義がないため、これらの部分すべてを推論する必要があります。
TRPCについて私が最も好きなことの一つは、今いるようなTRPCファイルを見ても、TypeScriptの行が一つもないということです。これは実際にはバニラJavaScriptです。このファイルには型定義がどこにもありません。このファイルは型推論を使用しています。したがって、入力は型付けされていません。入力は検証されています。
ここではvalibotを使用しています。通常、人々はZodを使用しますが、この時点で何でも使用できます。戻りには型がありません。options: some stuffのようなことはしませんでした。opsを置いただけで、それが推論されます。これは私の意見では、TypeScriptを書く正しい方法です。
絶対的に最低限、戻りタイプの記述を可能な限り避けるべきです。なぜなら、TypeScript戻りタイプは、返している物の型を覆い隠す可能性があるからです。まだ見ていない場合は、それについてずっと前からビデオを作っています。今これをすべて説明している理由は、TRPCのようなツールが行う推論の量を強調したかったからです。すべてが推論されているため、変更を行うと、すべてが下から上に再推論される必要があるという問題が発生します。
ここで戻りタイプを変更し、この戻りでこのtierをコメントアウトしただけで、TRPCルーターのすべての部分がその変更のために再計算される必要があります。これは変更が発生するたびに起こります。また、すべての新しいエンドポイントがすべてのエンドポイントの再チェックを必要とするn*n型の問題も発生します。
これにより、TypeScriptサーバーの性能が悪化し、TypeScriptコンパイル時間があるべきより悪くなることを意味します。エディターの性能があるべきより悪くなることを意味します。あるべきよりもはるかに多くのコマンド+シフト+PでTypeScriptサーバーを再起動することを意味します。良くありません。
専門家Davidの登場とArcTypeの紹介
TRPCは性能において大きな進歩を遂げていますが、まだあるべき場所にはありません。だからこそAlexと私はArchypeの作者であるDavidに連絡を取り、これを修正しようとしました。Davidについてまだよく知らない場合は、知っておくべきです。彼の仕事は素晴らしいです。Arcypeは圧倒的に最も性能の良いバリデーターです。
バリデーターと言うとき、私が意味するのは、ランダムなJSONのblobをチェックし、出力が正しい値であることを確認するツールのことです。エンドポイントやフォームなど、ユーザーがデータを送信できる場所がある場合、それらが正しい形で送信しているかどうかわかりません。そのblobを検証して、ユーザーが言っていることや期待していることと同じであることを確認するためのソリューションが多くあります。
昔よく使用していたOGのものはYupでした。Zodが登場し、よりTypeScriptに焦点を当てており、より強力でした。そして今、ArchypeやValibotのような、さらに性能が良く、潜在的により有能なソリューションもあります。バリデーターの世界は少しクレイジーになりました。
スキーマ検証は現在全体的に非常に良い状態にあり、Arcypeがその主な理由の一つです。Davidと他の貢献者によってここで行われた作業の結果として、クラフト全体を前進させたからです。また、Arcypeでの彼の作業と、さらに重要なことに、Arcypeのようなツールのベンチマークを作成する彼の作業から、TypeScriptサーバー性能に対する彼の理解は比類がないことが非常に明確です。だからこそ私たちは連絡を取りました。
プロジェクト参照とキャッシュ問題の発見
特に大きなプロジェクトでTRPCがどのように機能するか、特にプロジェクト参照がTRPCプロジェクトで機能しないように見える理由について分析を行うことになりました。プロジェクト参照について馴染みがない場合、これはTypeScriptコードベースに線を引く方法の一種で、「これは独自の別のサブツリーです。結果をキャッシュし、サブツリー内で何も変更されない場合は、そのキャッシュ結果を再利用してください。向こうで他の部分を変更した場合、ここの部分を再チェックする必要はありません」と言う方法です。
これは大いに役立つはずでした。ここの各ルーターにプロジェクト参照を行う場合、billing router、account services router、auth routerにそれぞれ一つずつ置く場合、ここで他の何かを変更するときに、これらのどれもチェックされるべきではありません。しかし、そうではありませんでした。
私たちが知る限り正しく設定されたプロジェクト参照があっても、性能問題が見られていました。これはDavidを強く興味をそそり、彼は理解しようとして調査に入りました。彼はTRPCで改善できる小さなことをいくつか見つけましたが、それほど多くはありませんでした。
代わりに最終的に見つけたのは、TypeScript自体のいくつかの奇妙なキャッシュ動作でした。特に、チェーンを持つ大きなオブジェクト全体でこれらのより深いネストされたマッピングを行うとき、キャッシュが基本的に壊れました。
DavidはこれをAndarist、最も伝説的なTypeScript貢献者の一人に見せました。実際、彼がMicrosoftでTypeScriptに取り組んでいないことは少し面白いです。なぜなら、Microsoft従業員ではない最も多産な貢献者であることはほぼ確実だからです。この時点で最も多産な貢献者の期間内にさえいるかもしれません。Andaristがここでものを修正している頻度は狂気的です。
私は命にかけて誓いますが、TypeScriptでPRをチェックしている時の半分は、彼が行ったことです。彼はこれらのことをより良くするために一生懸命働いています。そこで彼もこれに興味をそそられ、飛び込んで、これを潜在的に修正するために2つの異なるPRを作成しました。
具体的な問題の詳細分析
これらの例を見て、正確に何が問題なのかを見てみましょう。いつものように、Andaristは素晴らしい説明を書きました。ここにmerge typeがあります。これは2つの型を取り、それらのキーを一緒にマージする汎用マージ型です。ここにP1とP2があり、これらをP1 as numberとP2 as numberを持つ新しい型にしたいと思います。ここでも同じことをP3、P4で行いたいと思います。わかりますよね。そして、ここで壊れています。そして、ここで再び壊れています。特定のレベルのネストで失敗し始めるのは非常に面白いです。良くありません。
ここでは、カスタム型を作成してそれをあまり悪くしないようにしましたが、それでもこれらのチェックでのネストレベルとキャッシュが失敗する方法のために、比較的早くに失敗し始めます。また、これを開いて特定のTypeScriptバージョンで実行すると、型チェッカーが再実行されていることに気づくでしょう。
どれほど遅いか見てください。一見非常にシンプルに見えるこのコードをまだロードしているのです。しかし、いいえ。それは永遠にかかり、まだ壊れており、これらの多くの型について正しくありません。良くありません。
TypeScriptチームによる修正の実装
では、これについて何をするつもりでしょうか？私はこれを調査し、見つけたことは、これらの型が同じベース型を参照しているということです。それらはそれらからチェーンされ、instantiateTypeはそれらに対して多くの作業を繰り返します。問題の少なくとも一部は、getObjectTypeInstantiationがinstantiateType types.alias arguments mapperを呼び出してキャッシュキーの一部を作成することです。したがって、それらをインスタンス化する前に結果がキャッシュされているかどうかをチェックすることさえできません。この問題は、このような長いチェーンで大きく複合されます。それがここでの鍵です。
キャッシュにヒットするためのキーの一部としてinstantiateType呼び出しを使用しているため、キャッシュにあるかどうかを確認するためだけに呼び出しを行っています。したがって、チェックを避ける方法はありません。その結果、TRPCやZODのようなツールを使用する大きなコードベースで、これらのマージが多数ある場合、非常に厳しい性能になります。彼らは積極的に壊れます。
これはテストスイート全体でインスタンス化カウントに非常にポジティブな影響を与えているようです。しかし、メモリをトレードオフすることは確実です。これとextended test suite runのPerfの結果を見るのは興味深いでしょう。編集。Davidはここで、いくつかのTRPCベースのリポジトリでこれをテストし、チェック時間が半分になったと述べています。現在のバージョンは、追加されたlong star testsで見ることができるように、50アイテムの深いチェーンを型チェックすることもできます。
以前は15から25のような特定の深さまでしかインスタンス化できませんでした。チェーンの最後のアイテムは本当に遅くインスタンス化されていました。今、それらのより長いものはすべて非常に高速に処理されます。このPRがどれほど大きいかも実感していませんでした。それは巨大な変更です。興味深いです。テストテストの結果が変更されたからかもしれませんか？コードを見ていません。
そうです、見た感じ、主にテストの変更です。多くのテストが変更されました。理にかなっています。しかし、実際のコード変更は比較的小さいです。2319行の中にあります。なぜなら、TypeScript全体のように型チェッカーファイルは、この一つの巨大なチェッカーファイルだからです。非常に興味深い構築方法です。
コードがライン2319から2322で変更されました。他のコードは20,000番台で変更されました。非常に楽しいです。ここで新しいアクティブマッパーキャッシュを定義しています。そして、ここでそのマップキャッシュをチェックし、実行しているキーに基づいて正確なキャッシュ値がある場合はそれを使用しています。素晴らしい変更です。比較的シンプルです。
すべてのTypeScriptへの変更がそうであるように、戦いを引き起こしました。正直言って、おそらくそうあるべきです。非常に重要なプロジェクトです。これらを間違えることは危険です。しかし、性能の向上はどうでしょうか？
性能改善の結果と@testによるベンチマーク
ここで、友人Davidによる@testを使用しています。@testは非常に楽しいベンチマークです。なぜなら、TypeScript自体を使用してTypeScriptをベンチマークするからです。
その方法は、マッピングやチェックが発生するたびに型定義内の値をインクリメントすることです。したがって、ここのこの数字は実際に型安全です。ここでの性能チェックは、コードを書くときに、ベンチのための型を作成し、その型は何ステップを経たかの具体的な数値であるということです。
コード自体は、何回のインスタンス化が発生したかの数値のために間違った数値を入れると型エラーになり、その数値に変更させるため、効果的に自己文書化されます。これは非常に面白いです。@testの仕組みです。これについて全体的なビデオがあります。とてもクールです。
これは実際にTypeScriptをベンチマークするビデオで、爆死しましたが、そのベンチマークと仕組みの詳細な解説です。高くお勧めします。関心があるなら説明にリンクを入れます。
ここで、このテストが59,000のインスタンス化を行ったことがわかります。これに、このマージリストにもう一つ値を追加しただけで、59,000から177,000になりました。もう一つの値で531,000にバンプしました。これらの数字がどれほど急速に上昇するかは非常に狂気的です。残念ながら、彼はそこで変更したときのベンチ値を入れませんでした。そして私は自分で再実行するのが面倒すぎます。
しかし、ここにあるのは、AndaristがTRPCベースのリポジトリでそれを実行したとき、TypeScript 5.8は12,33,763のインスタンス化がありました。このブランチはそれを817Kにほぼ半分にカットし、メモリ使用量をわずかに増加させながらチェック時間を半分以上カットしました。巨大な変更です。
この調査の一部は、彼が私の友人ReeによるオープンソースプロジェクトであるAnswer Overflowを調査したことから来ています。これは予想外で、見るのが本当にクールです。なぜなら、このuse mutationチェックは型チェックに2秒以上かかっていて、性能問題がどこにあるかを把握するためのオープンソーステストとして使用するのに非常に良い候補だったからです。伝統的なベンチマークではなく、確実にminimal reproでもありません。しかし、本当に有用でした。
しかし、その後彼はminimal reproを作成し、多くのベンチマークを行い、TRPCにも本当に深く関わっているオープンソースのカウンターリー代替案であるcal.comのようなもので大幅な性能改善を見ています。
面白いことに、TypeScriptの作者であるAnders Hejlsbergがここに飛び込んで、このアプローチはハッキーに見えるが、それを行う良いインセンティブがあると言いました。私はTSGOコードベースのJSXポーティング作業の最中です。それは再び、TypeScript Goが本当に重要だったからです。彼はすぐにこれをチェックするには、JSXをそれで動作させようとするのに気を取られすぎていました。
私はHejlsbergが数字を見たときに譲歩する意欲を愛しています。ここで彼はキャッシングの利益がそれほど素晴らしいとは確信していませんでしたが、これらのマイクロベンチマークでは、それがはるかに劇的であることがわかります。したがって、追加のキャッシングにメリットがあることに同意しますが、理想的には、すべてのインスタンス化をキャッシュするのではなく、高価なインスタンス化レベルでターゲットにしたいと思います。
キャッシュが常に無効化される可能性があることを懸念しています。完全に公正です。Alexは彼がそれに対処しようとすると言います。私は彼がそれを成功させたと信じています。そして、それがすべてマージされました。そして再び、ここで大きなギャップは、インスタンス化の数です。これらの変更により、型チェッカーが実際にこれらの型を生成してチェックする回数が78%削減されます。これは巨大な変更です。
そして今、nightly buildでは、型定義が50まで動作し続けることがわかります。ついに、この全体が機能し、それは少し狂気的です。P51は存在しないため失敗します。O2の形にはP3がないためエラーになるはずです。25にはP25があるはずです。
改善結果の素晴らしさと今後の展望
これがすべてうまく機能するようになったことは非常にクールです。この完全に有効なTypeScriptコードが以前は壊れて超遅く実行されていたのに、今は完全に良好で合理的になったことはどれほど狂気的でしょうか。これは奇妙で難解に見えるかもしれませんが、このタイプのマージタイプ関数は、ZODやTRPCのような私たちが毎日使用するツールにとって不可欠です。
私はこれに本当に興奮し、前述のように、この作業を行う人々に確実に支払いを受けてもらいたいと思いました。そこで、Arctypeに3000ドルを投げました。そして、あなたは何を知っていますか？Andaristにももう少し支払うつもりです。私はすでに彼に月50ドルを与えていますが、これは大きな問題です。はい。彼らにも支払いました。これらのことが皆さんに利益をもたらすなら、それを実現した人々に支払うべきです。
これらすべてを可能にするメンテナーをサポートすることは最低限できることです。しかし、前述のように、これはTypeScript 5.9で変更された唯一のことではありません。実際、5.9リリースでエディター体験にとって本当に大きな改善があり、私は非常に興奮しています。まだベータ版ですが、ほぼ確実に実際のコードベースにベータ版をインストールする予定です。
正直言って、皆さんもそれを検討すべきです。それほどスケッチではありません。これらのベータ版はMicrosoftによって非常にハードにバトルテストされます。したがって、TypeScriptベータの使用は完全に問題ありません。nightlyは避けてください。それらはスケッチですが、少なくともベータを使用したい場合は使用してください。それらは非常に良いです。
とにかく、彼らが改善したものを見てみましょう。tsc –initを更新して、今はminimalになっています。tsc –initは、既存のコードベースからコピーペーストしたり、すでに持っている別のコードベースinitツールを使用したりしたくない場合に、tsconfigファイルを作成する方法です。クール。素晴らしい。彼らがそれをはるかにシンプルで、よりバニラにしたのを見るのは素晴らしいです。そして、自分で追加したいかもしれないものをコメントアウトします。noUncheckedIndexedAccessがデフォルトでオンになっているのが気に入っています。
これは言語のデフォルトであるべきだったと私はまだ思っていますが、後で追加されたため、異なって行わなければならなかった理由は理解しています。import deferは本当にクールです。すぐに実行せずにモジュールをインポートし、その依存関係をインポートできます。後でコードでその実際を呼び出すかどうか、どのように呼び出すかを選択できます。
副作用を持つこのようなインスタンス化関数があり、その後値をエクスポートするコードがある場合、このimport deferは、インポートした場所から実際に何かを叩こうとするまでコードが実行されないことを意味します。Node 20の非常に素晴らしい新しいモジュールモード。DOM APIの要約説明を見るのはクールです。これは非常に素晴らしいものです。
DOM API改善とTypeScript体験の向上
TypeScriptのDOM APIは、APIのMDNドキュメントにのみリンクしていました。これらのリンクは有用でしたが、APIが実際に何をするかの簡単な要約を提供していませんでした。ここでAdam Nagiからのいくつかの変更のおかげで、見た目では、Microsoft のメンバーでもありません。面白いことに、Flutter開発者でもありますが、TypeScript貢献者であり、ここで本当にクールな変更を行いました。
DOM関連のTypeScriptとJavaScriptライブラリファイルを生成するためのツールです。これは非常にクールです。typesパッケージのようなTypeScriptリリースに含まれます。これは超クールです。いいものです。信じられないかもしれませんが、ブラウザには音楽に関することを行うためのMIDI APIが実際にあります。今、この小さな説明が得られます。
Web MIDI APIのMIDI出力インターフェースは、出力デバイスのキューにメッセージを追加し、メッセージのキューをクリアするメソッドを提供します。セキュアコンテキストでのみ利用可能。これは以前のものよりもはるかに有用です。
582を選択し、上にカーソルを合わせると、セキュアコンテキストでのみ利用可能とMDN参照が得られます。これは大幅な改善です。小さく見えることは知っていますが、これらの小さなことは重要であり、TypeScriptを使用するのを快適な体験にするためにTypeScriptチームが行う作業の大きな部分です。それだけでなく、これによりTypeScriptがJavaScriptよりも快適な体験になります。
これらの有用なWebスタンダードがJSよりもTSでより良い体験になるのは、言語サーバーにより良く統合されているからです。非常に素晴らしい。これらのことは小さく見えることは知っていますが、素早く積み重なります。そして、今日のTypeScriptを昨年のTypeScriptより良くするのは、このタイプの改善すべてです。
展開可能なホバーの革命的機能
そう言えば、おそらく圧倒的にクールな変更は展開可能なホバーです。これはそれ自体の専用ビデオを作りたいと思ったほど、非常にクールな勝利です。少なくともこのビデオの最初でヒントを出したかったのです。忘れてしまいました。まあ、それはそれです。これは、ビデオをここまで見た人への報酬です。
ちなみに、ここまで来てまだ購読していないなら、何をしているのですか？購読するのにお金はかからず、チャンネルの助けになります。まだの場合は、その小さな赤いボタンを押してください。とにかく、私たちは皆、ここで見る問題を抱えていました。optionsのようなタイプがあり、それにカーソルを合わせると、options: optionsと表示されるだけです。それは有用ではありません。optionsの実際のタイプが何であるかを知りたいのです。ここでは何も見ることができません。
optionsをコマンドクリックして他の場所を見に行くことはできますが、それでは十分ではありません。理想的にはここで知りたいのです。彼らが私たちに与えたものを見てください。これがどれほど革命的か理解していますか？私のチャットを見せましょう。彼らはeffectを使用可能にしました。OMG、美しい。すごい、これは私が必要だったものです。おお、すごい、おお神様。ついに。そうです、これは本当に良いリリースになるでしょう。
また、VS Codeのようなエディターを使用している場合と具体的に言っているのが好きです。cursor、wind surf、treyに対する軽いシェードです。面白いです。この機能は現在プレビュー中で、TypeScriptとVS Codeのパートナーの両方からフィードバックを求めています。詳細については、この機能のPRを参照してください。
この機能を本当に興奮しているので、デモしようと手間をかけました。そして、VS Codeの最新バージョンで設定をオンにしているにもかかわらず、ここで見ることができるように動作していません。VS Code Insidersのような早期アクセスビルドやベータビルドを使用していれば、おそらく動作するはずです。しかし、ここで見るように、これが存在し、動作するはずだと知っているにもかかわらず、残念ながら私には動作していないようです。
今のところリップですが、これがまもなく来ることを知ってください。そして、うまくいけばVS Codeに入った直後に、私たちが時間を過ごすすべてのVS Codeフォークもこれを取得するでしょう。私は個人的に、これをASAPで取得することを確実にするために、Cursorの友人たちを煩わせるつもりです。
設定可能な最大ホバー長の改善
設定可能な最大ホバー長は、今まで見逃していたものです。そして、これは実際に本当に、再び小さいですが、非常にエキサイティングです。このデモで以前チェックしていたものを見て、ここで020にカーソルを合わせると、特定のポイントに達するまで完全な型定義が得られ、その後これらの省略された三点が得られることがわかります。ここでは問題ありませんが、少し下にスクロールすると、実際には何も節約していないことがわかります。ただ情報を削除しているだけです。
省略しているからと言って、これを読みやすくしているわけではありません。ただ迷惑なだけです。したがって、省略を開始するまでの長さを延長する能力は本当に素晴らしいです。私が強く推奨し、絶対に愛しているパッケージがあります。Pretty TypeScript Errorsです。
小さくてシンプルに聞こえますが、実際にはライフチェンジャーです。なぜなら、これらのエラーを解析し、TypeScriptが行うすべての省略や処理を処理し、実際に何かが失敗している場所を見るために、エディターではるかに良いフォーマットを提供するからです。これは読めないスロップです。これを精神的に解析して、ここで何を言うはずなのかを理解することはありません。実際に読めて、良いフォーマットを提供します。
拡張機能は、VS Codeがこのビュー内で意味のあるものをレンダリングする能力を実際に提供していないため、動作させるためのハックの山です。それが小さすぎて手動で展開しなければならない理由は、実際にTypeScriptとVS Codeがこれを正しい方法で行うために必要な露出を提供していないからです。
この拡張機能が行うソリューションと回避策は、これをすべてSVGアイコンとしてレンダリングすることです。ここで得ているのは、実際にはここのすべてのコンテンツであるアイコンです。だからこそ、SVGとしてアイコンとしてレンダリングされているため、中のテキストを選択できないのです。これは非常にクールです。しかし、ここのリンクはまだ機能し、これは素晴らしいです。
TypeScriptエラードキュメントへのこのリンクを取得でき、エラーを説明してくれる友人Matt POCOによるプロジェクトであるTS error translatorに連れて行くこのリンクを取得できます。かなりクールです。これをすべて説明する理由は、エディターで読みやすいフィードバックを持つことが重要だからです。省略の努力は評価しますが、少し積極的すぎて、このプロジェクトでの作業の多くは積極的な省略を回避しようとすることです。ホバーで最大長を上げることができれば、
ずっと良くなるでしょう。また、それを完全に無効にすることもできるようで、これはクールです。良いものです。
その他の性能改善と今後の展望
他に何を見逃したでしょうか？以前に話したもの、私がかなりのお金をかけて実現した性能改善であるマッパーでのキャッシュインスタンス化があります。そして、ソースを使用してファイルまたはディレクトリが存在する場合のクロージャ作成の回避です。
関数式は、ラッパー関数がキャプチャされた変数なしで引数を別の関数に渡すだけの場合でも、通常は新しい関数オブジェクトを割り当てます。ファイル存在チェックを回避するコードでは、Vincent Baileyは、基礎となる関数が単一の引数のみを取ったにもかかわらず、これらのパススルー関数呼び出しの例を見つけました。
これは、特定のケースや大きなプロジェクトで型チェックを最大11%高速化したソリューションです。非常にクールです。
では、次は何でしょうか？明らかに、TypeScriptのネイティブポート、つまりGolangでの書き直しは、最終的にTypeScriptバージョン7として利用可能になるでしょう。TypeScript nativeプレビューに行くことで、今日ネイティブポートをチェックできます。これらは現在、インストールして使用できます。毎晩リリースされています。
彼らはまだTypeScript 5.9を開発し、問題に対処しており、試してフィードバックを得ることを奨励しています。これらの変更が提案されたときに私たちが抱えていた大きな懸念の一つでした。Goでのこの大規模なオーバーホールと書き直しの最中に、TypeScriptチームが型チェックの仕組みに意味のある変更を行うことを躊躇するのではないかと恐れていました。
そのような大きなオーバーホールをしているときに、あなたの下でターゲットが動くのは嫌です。したがって、TypeScriptチームがこの書き直しを並行して行いながらも、このような変更を検討し、深くレビューし、最終的にマージすることを喜んで行っていたのを見て、本当に興奮しました。
これはTypeScriptチームについて多くを語っており、TypeScript言語が能力の最善を尽くして私たちユーザーに奉仕することを確実にしたいという彼らの思いを示しています。このすべてを助けるために行った作業について、チームに非常に感謝しています。これは本当にクールで、私の意見では非常に過小評価されているTypeScriptリリースです。私と同じくらい興奮していることを願っています。これで今回は以上です。皆さんがどう思うか教えてください。
コメント