Pack
ドキュメント
Turbopackを選ぶ理由

Turbopackを選ぶ理由

Turbopackを作成するにあたり、私たちは問題を解決したいと考えていました。私たちはNext.jsの速度改善に取り組んでいました。いくつかのJSベースのツールからの移行を進めました。Babelは不要になり、Terserも不要になりました。私たちの次のターゲットは、別のJSベースのツールであるwebpackでした。

webpackを置き換えることが私たちの目標になりました。しかし、何で置き換えるのでしょうか？

新世代のネイティブスピードバンドラーが登場していましたが、市場に出回っているバンドラーを評価した結果、私たちは独自のものを構築することにしました。なぜでしょうか？

統合グラフ

Next.jsのようなフレームワークが非常に人気になった大きな理由の1つは、現在の世代のバンドラーでSSR（現在はRSC）のような機能を実装するのが簡単ではないということです。各出力環境（ブラウザ、サーバーなど）に対して複数のコンパイラを作成し、それらのバンドルが正しく結合されるようにコンパイラ間の通信を管理する必要があります。

私たちは、Next.jsやTurbopackを使用することを選択するあらゆるフレームワークから、このメンテナンスの負担を取り除きたいと考えていました。また、複数の環境のバンドルを生成するために使用できる単一の統合グラフを設計することで、よりクリーンで安定した実装を作成することもできます。

バンドル vs ネイティブ ESM

Viteのようなフレームワークは、開発モードではアプリケーションのソースコードをバンドルしないという手法を使用しています。代わりに、ブラウザのネイティブESモジュールシステムに依存しています。このアプローチでは、単一のファイルを変換するだけで済むため、非常にレスポンシブな更新が可能です。

私たちはこのアプローチを試してみましたが、多数のモジュールで構成される大規模なアプリケーションでは、スケーリングの問題に直面しました。ブラウザでのカスケードネットワークリクエストの急増により、比較的遅い起動時間につながりました。ブラウザの場合、必要なコードをできるだけ少ないネットワークリクエストで受信できる方が、ローカルサーバー上でも高速です。

そのため、webpackと同様に、開発サーバーでコードをバンドルしたいと考えました。TurbopackはRustで記述されており、本番環境にのみ必要な最適化作業をスキップするため、特に大規模なアプリケーションの場合、はるかに高速に処理できます。

増分計算

プロセスを高速化するには、2つの方法があります。作業量を減らすか、並行して作業を行うかです。最速のバンドラーを作成したいのであれば、両方のレバーを強く引く必要があると私たちは考えました。

私たちは、分散型および増分型の動作のために、Parcelのリクエストマネージャーやrustcのクエリシステムと同様の、再利用可能なTurboビルドエンジンを作成することにしました。Turboエンジンは、関数呼び出しのスケジューラーとして機能し、関数への呼び出しをすべての利用可能なコアで並列化することができます。

Turboエンジンは、スケジュールしたすべての関数の結果をキャッシュするため、同じ作業を2回行う必要はありません。簡単に言えば、最小限の作業で最大の速度を実現します。

遅延バンドル

Next.jsの初期バージョンでは、開発モードでWebアプリ全体をバンドルしようとしていました。この「eager」なアプローチは最適ではないことにすぐに気づきました。Next.jsの最新バージョンでは、開発サーバーによって要求されたページのみをバンドルします。たとえば、localhost:3000にアクセスすると、pages/index.jsxと、それがインポートするモジュールのみをバンドルします。

このより「遅延」したアプローチ（本当に必要な場合にのみアセットをバンドルする）は、高速な開発サーバーにとって重要です。ネイティブESMは、それほど魔法を使わずにこれを処理します。モジュールをリクエストすると、他のモジュールをリクエストします。ただし、上記の理由から、私たちはバンドラーを構築したいと考えました。

esbuildには「遅延」バンドルの概念がありません。特定の開始点のみを対象としない限り、すべてか無しかです。

Turbopackの開発モードでは、受信したリクエストに基づいてアプリのインポートとエクスポートの最小限のグラフを作成し、必要な最小限のコードのみをバンドルします。詳細については、コアコンセプトのドキュメントを参照してください。

まとめ

私たちは次のことを望んでいました。

  • 統合グラフをサポートする。これにより、フレームワークは複数の環境をターゲットにできる単一のコンパイラーを使用できます。
  • バンドラーを構築する。バンドラーは、大規模なアプリケーションで作業する場合、ネイティブESMよりも優れたパフォーマンスを発揮します。
  • 増分計算を使用する。Turboエンジンは、これをTurbopackのアーキテクチャの中核に取り込み、速度を最大化し、作業量を最小限に抑えます。
  • 開発サーバーの起動時間を最適化する。そのため、リクエストされたアセットのみを計算する遅延アセットグラフを構築します。

それが、私たちがTurbopackを構築することを選択した理由です。