Rspack は非常に興味深い技術トピックであり、将来のポッドキャストのゲストでもあります。ここでは、クイックレビューを行います。
今回は、バイトダンスの Rspack の原理と実践を読み込みます。バイトダンスの杨健
杨健 - 字节跳动 Rspack の原理与实践
公式ウェブサイト：rspack.dev
いくつかの共有コンテンツの原文と感想がありますが、原文は明記し、感想を主にします。
原稿の概要
- Rspack の理由
- 特徴
- エコシステムの互換性
- プラグアンドプレイの能力
- ビジネスパフォーマンスの利益
- アーキテクチャ設計
- 移行ガイド
Rspack の理由#
webpack は十分に優れていない#
会社内には多くの巨大なアプリケーションがあり、プロジェクトの起動が遅く、冷起動が遅く、ビルドが遅いです。
従来の webpack の最適化手法は、古い手法であり、例えば babel -> swc-loader、esbuild/vite などがあります。
これらの解決策には利点がありますが、完全に解決することはできません。たとえば、swc-loader はローダーを高速化できますが、完全ではありません。
vite は dev が速いですが、rollup のビルドは webpack よりも速くありません。
esbuild はプロダクションの最適化が速いですが、dev-hmr をサポートしていませんし、パッケージングの能力も制限されています。
ここで、vite と rspack のどちらが良いかという質問に答えましたが、答えはありません。シーンと極端なパフォーマンスによります。たとえば、開発体験、ssr ですが、重いプロジェクトのビルドには違いがあります。
ただし、rspack 自体は低レベルであり、vue-cli の移行は少し手間がかかります。
良いビルドツールの特徴#
それは開発者の要望です
- パフォーマンスが良く、冷起動が速く、hrm が速く、ビルドが速く、数十回のビルドがある場合でも。
- 柔軟性、設定が柔軟で、さまざまな使用シナリオに対応できること。toC のビルドアーティファクトのサイズ、toB の巨大なアプリケーションのスケーラビリティ
- プロダクションのパフォーマンス：コード分割、treeShaking、初期表示など
- アプリケーションのシナリオ、webapp+node.js + クロスプラットフォーム
- 移行コストが低く、ビジネス側が抵抗しない
このように見ると、webpack が最も優れています。たとえば、swc/esbuild/vite などのツールは、伝統的なプロジェクト、クロスプラットフォームプロジェクトに対してまだ多くの改善の余地があります。
rspack がやってくれる！#
rspack には多くの利点があります：
- rust による実装で、ネイティブ能力が強い
- インクリメンタルコンパイル、高速な hrm
- webpack エコシステムの互換性
- プラグアンドプレイで ts/tsx/css/css modules をサポートし、プラグインを探す必要はありません
- デフォルトでさまざまな最適化戦略があり、tree shaking/code splitting などのコードの圧縮など
互換性が良く、一部を紹介しました。そして、一般的なプラグインも見ました。
また、自分で試行錯誤する必要がなくなったので、ts を使う必要はありません。babel-loader/ts-loader は必要ありません。かつての悪夢です。
CSS も以前は面倒でしたが、パッケージ化、css/style loader などが組み込まれています。ただし、less/sass の設定が必要です。比較スクリーンショットがあり、rspack の方が簡単です。主に、less-loader が css と css/module を終了させ、組み込み処理を行います。
互換性が語られ、パフォーマンスの利益が良いということです。3 つの指標、dev の冷起動、hrm、プロダクションのビルド。
グラフィックがありますが、省略します。rspack のパフォーマンスは非常に良いです。特にプロダクションのビルドでは rollup はまだ対応していません。
利益#
ベンチマークを終えたので、実装について話しましょう。内部プロジェクトでは、webpack に比べて大幅な改善があります。
webpack では 1 つの hrm に 20 秒かかりますが、想像できません...、最適化後は 1 秒です。
よくある質問#
よくある質問に答えることができます：
なぜ node + js ではないのですか？#
- webpack は長年にわたるシングルスレッドの努力で、パフォーマンスの限界があります
- node 自体はシングルスレッドであり、マルチスレッドではありません
- マルチスレッドをサポートするために worker-thread を使用し、新しい v8 インスタンスを作成してシングルスレッドをシミュレートします。通信プロセスにはシリアライズとデシリアライズが必要であり、データ共有の効率が低いです
- 並行エコシステムが不足しています。v8 のマルチスレッドサポートが十分に良くないため、パフォーマンスの消費が大きく、並行プログラミングのエコシステムが不足しています
なぜ golang - esbuild ではないのですか？#
- golang のパフォーマンスは十分です
- napi のサポートが不十分であり、満足のいく結果を得ることができません
- esbuild には ast を操作するための API が提供されておらず、es5 へのダウングレードがサポートされていません
なぜ rust なのですか？#
- パフォーマンスが良い
- napi のサポートが良く、rust マクロのサポートがあり、テンプレートコードを少なく書くことができます
- rust は webAssembly をサポートしており、rust はより進んだリードを推進しています
- rust の swc は ast の操作を豊富にサポートしており、es5 へのダウングレードもサポートしています
swc だけではダメですか？#
大企業が力を発揮しました。
- swc の並行解析が悪いことがわかり、dev のプロファイラでパーシングがボトルネックであることがわかりました。さらに、低レベルのライブラリのバグも見つかりました。
なぜまだ js をプラグイン拡張に使用するのですか#
- js は馴染みがあり、rust は馴染みがなく、コストが高く、柔軟性に欠けます
- ダイナミックな機能、rust は js ほどダイナミックではなく、コンパイルアーティファクトはマシン環境に依存する可能性があり、差異があるかもしれません。クロスプラットフォームの処理が面倒で、10 以上のプラットフォームのアーティファクトをコンパイルする必要があるかもしれません。ハードルが高く、安定性も十分ではありません
速い原理#
- アーキテクチャは Webpack 5 に基づいています
- rust を採用する
- babel を swc に変更し、loader が遅いため、一般的には swc/esbuild を使用して高速化します。
- rust と js の通信には napi-rs を使用し、v8 はバッファ文字列に基づいて通信し、マルチスレッドのサポートが不十分で、複雑なデータ構造の通信が困難です。たとえば、ast はシリアライズ通信しか選択できません。シリアライズとデシリアライズのオーバーヘッドは非常に大きいです。しかし、rust のマルチスレッド共有はシンプルで、ほとんどオーバーヘッドがありません。マルチコアのパフォーマンスが優れています。
アーキテクチャ図がありますが、見たことがありません。Webpack のアーキテクチャ図と似ていると言われています。（私は経験がないので、2 回聞きました）
make pase ビルド依存グラフモジュールグラフ
/seal フェーズ。依存グラフからチャンクを生成します
- 最適化分析、モジュールの使用、副作用の分析
- チャンクグラフの作成
- パッケージング、モジュールグラフ
- ID の生成
- モジュール ID の生成
- チャンク ID の生成
- モジュールコードの生成
- ランタイムモジュール
- チャンクリソースの生成
- リソースの生成
パッケージキャッシュ戦略はビジネスと区別する必要があり、パッケージを並列にロードします。
ユーザー設定の polyfill es5-es6-esnext など
この部分は非常に興味深いです、初めて聞きました。
黄色の部分は並列に処理できますが、rust の方が速いです。webpack はマルチスレッドの処理がうまくいかず、thread-loader を使用しても通信が困難ですが、rspack は 2 つの欠点を解決しました。
核心：並列処理できるすべての場所で並列処理します。マルチコアで 1.7 倍のパフォーマンス向上がありますが、まだオーバーヘッドがあります。ただし、webpack の限定的なパフォーマンス向上（1.1 倍 - 1.2 倍）よりも優れています。
既存のビジネスの移行#
- 組み込まれた機能を使用する、例えば js/ts/css/file-loader/html-plugin など
- たとえば、html-plugin プラグインの柔軟性が十分ではないため、js バージョンのプラグインも組み込まれており、拡張が容易ですが、少し遅いです
- サードパーティのプラグインはサポートされていませんが、追加できます
ロードマップの展望
- webpack エコシステムの互換性
- より多くのフレームワークのサポート
- 永続キャッシュのサポート、遅延コンパイル
- より多くのプロダクション最適化
- mf のサポート
聞いた展望
うーん、webpack のアーキテクチャを読み込み、最適化の方向性を指摘しましたので、rspack はそれを実現しています。
尊敬すべき経験があり、詳細はわかりませんが、もっと見る必要があります。