2024年5月28日
Rspack v0.7 がリリースされました!
これは Rspack v1.0 までの最後のマイナーリリースです。 今後、Rspack チームは v1.0 の開発に注力し、近日中に Rspack v1.0 アルファ版をリリースすることを目指します。
Rspack v0.7 の主な変更点
Rspack v0.7 は、マルチページアプリケーション (MPA) や大規模なシングルページアプリケーション (SPA) の開発起動パフォーマンスを向上させるのに非常に役立つ遅延コンパイルをサポートするようになりました。
遅延コンパイルは、起動パフォーマンスを向上させるための優れた方法です。起動時にすべてのモジュールをコンパイルするのではなく、オンデマンドでモジュールをコンパイルします。 これにより、開発者は開発サーバーを起動したときにアプリケーションがすぐに実行されていることを確認し、必要なモジュールを段階的にビルドできます。
Rspack 自体は優れたパフォーマンスを備えていますが、モジュール数が非常に多いアプリケーションをビルドする場合、全体のビルド時間は依然として理想的とは言えません。 これは、アプリケーション内のモジュールが `postcss-loader`、`sass-loader`、`vue-loader` などのさまざまなローダーによってコンパイルされる必要があるため、追加のコンパイルオーバーヘッドが発生するためです。
遅延コンパイルを有効にすると、Rspack はリクエストされたエントリポイントと動的インポートモジュールのみをコンパイルします。 これにより、開発起動時にコンパイルされるモジュールの数が大幅に削減され、起動時間が短縮されます。
次のシナリオを考えてみましょう
あなたのチームは、数十ページの MPA アプリケーションを開発しています。 ほとんどの場合、あなたは少数のページでのみ作業し、他のページのコードをビルドする必要はありません。 この場合、遅延コンパイルを有効にして、Rspack がアクセスするページによって参照されるモジュールのみをコンパイルできるようにすることができます。
遅延コンパイルが有効になっている場合、Rspack は「エントリポイント」と「動的インポート」を分割ポイントとして扱います。 例えば
a.js をコンパイルすると、Rspack は b.js を空のモジュールとして扱い、まるでコードが書き込まれていないかのように扱います。 b.js にアクセスする必要があるとすぐに、Rspack は b.js モジュールに元のコンテンツを埋め込み、ユーザーがそのコードを書き込んだかのようにします。
Rspack ドキュメントサイトを例にとると、いくつかのページが含まれています。 遅延コンパイルが有効になっている場合、エントリポイントとそれらに依存するモジュールのみがビルドされます。 これにより、起動速度が大幅に向上し、起動時間が 2.1 秒から 0.05 秒に短縮されます。
開発者がサイトの特定のページにアクセスすると、そのページのビルドがトリガーされます。 このビルド時間は、フルビルド時間よりも大幅に短縮されます。
experiments.lazyCompilation 設定を通じて、Rspack で遅延コンパイル機能を有効にすることができます
現在の遅延コンパイルは webpack の実装と一致しており、**まだ実験段階**であることに注意してください. 一部のシナリオでは、遅延コンパイルが期待どおりに機能しない場合や、パフォーマンスの向上がわずかである場合があります。
より安定した状態を実現するために、さまざまなシナリオで遅延コンパイルの使いやすさを引き続き改善していきます。 使用中に問題が発生した場合は、GitHub Issues からフィードバックをお寄せください。
v0.7 では、experiments.css の内部実装をリファクタリングしました。
CSS 依存関係分析のために、Rust を使用して css-module-lexer を開発しました。これは、CSS または CSS Modules を解析し、それらの依存関係メタデータを返す高性能なレクサーです。
css-module-lexer の統合により、Rspack はより複雑な CSS Modules 構文をサポートできるようになり、その動作は webpack の `css-loader` と一致するようになりました。 たとえば、次の CSS Modules 構文をサポートできます
リファクタリング前後の CSS 解析プロセスを以下の図に示します
`css-module-lexer` は、Rspack の `experiments.css` にも大幅なパフォーマンス向上をもたらしました。 パフォーマンステストでは、`bootstrap.css` のビルドパフォーマンスが約 4 倍向上しました。
Rspack はバージョン 1.0 より前にすべての不安定な API と設定を徐々に削除し、より多くの設定 / API / デフォルトの動作が webpack と一致するようになります.
Rspack は、内部使用のみを目的とした不安定な API ( `compiler.compilation` や `compiler.builtinPlugins` など) を早期に公開していました。 これらの API は安定しておらず、webpack では使用できませんでした.
v0.7 では、現在公開されている API とそのインターフェース定義を再編成しました。 これらの API を使用していた場合は、webpack と一致する実装に合わせて必要な調整を行う必要があります.
次の API は廃止されました
compiler.builtinPlugins
compiler.compilation
compiler.compilationParams
compiler.getAsset(name)
statsError.formatted
statsWarning.formatted
廃止された API の詳細については、rspack#6448、rspack#6505 を参照してください.
Rspack 0.7では、experiments.cssの内部実装を部分的にリファクタリングしました。
リファクタリング後、@import
が先頭にない場合、以下のエラーが発生します。この場合は、@import
ルールを手動で先頭に調整する必要があります。
v0.7では、builtins.treeShaking
(旧ツリーシェイキング)とexperiments.rspackFuture.newTreeshaking
(新ツリーシェイキングスイッチ)の設定が削除され、旧ツリーシェイキング機能は完全にオフラインになりました。
この設定はresolve.aliasFields = ["browser"]
の省略形であり、Rspackは既にresolve.aliasFields
をサポートしているため、この設定は不要になりました。
この設定は、新しいsplitChunks実装を有効にするために使用されていましたが、Rspackは既にデフォルトで新しいsplitChunks実装を使用しているため、この設定は不要になりました。
この設定は、キャッシュ使用時のスナップショット戦略を制御するために使用されていました。Rspackの現在のインクリメンタルリビルドアーキテクチャでは、キャッシュはスナップショットに依存しなくなったため、この設定は不要になりました。
この設定は、experiments.cssでCSSモジュールエクスポートの命名規則を制御するために使用されていました。これは、エクスポートを持つモジュールタイプcss/module
のモジュールにのみ影響します。モジュールタイプcss
のモジュールにはエクスポートがないため、この設定は不要です。
Rustクレートswc_core
を0.91.x
にアップグレードしました。これは、SWC Wasmプラグインのユーザーに影響します。
バージョンv0.7では、Rustクレートswc_core
が0.91.x
にアップグレードされました。 SWC Wasmプラグインのユーザーは、使用されているswc_core
とのバージョンの一貫性を確保する必要があります。そうでない場合、予期しない問題が発生する可能性があります。
詳細については、SWCのドキュメントをご覧ください。
以前にresolve.browserField
を設定していた場合は、resolve.aliasFields
に置き換える必要があります。
resolve.browserField = true
は resolve.aliasFields = ["browser"]
に置き換えられますresolve.browserField = false
は resolve.aliasFields = []
に置き換えられます以前にmodule.generator.css.exportsConvention
またはgenerator.exportsConvention
をmodule.rule
で設定していた場合は、その設定を削除するだけで済みます。
Rsbuild v0.7がRspack v0.7と共にリリースされました。詳細については、Rsbuild v0.7の発表をご覧ください。