Rspack 0.7 リリースのお知らせ

2024年5月28日

Rspack v0.7 がリリースされました!

これは Rspack v1.0 までの最後のマイナーリリースです。 今後、Rspack チームは v1.0 の開発に注力し、近日中に Rspack v1.0 アルファ版をリリースすることを目指します。

Rspack v0.7 の主な変更点

  • 遅延コンパイルのサポート: オンデマンドでコンパイルすることにより、大規模アプリケーションの開発起動パフォーマンスを大幅に向上させます。
  • CSSビルドの高速化: 新しい css-module-lexer を導入し、CSSバンドル速度を 4 倍向上させます。
  • 破壊的な変更: デフォルトの動作を webpack とより一致させるために、いくつかの不安定な API を削除しました。

遅延コンパイルのサポート

Rspack v0.7 は、マルチページアプリケーション (MPA) や大規模なシングルページアプリケーション (SPA) の開発起動パフォーマンスを向上させるのに非常に役立つ遅延コンパイルをサポートするようになりました。

遅延コンパイルとは

遅延コンパイルは、起動パフォーマンスを向上させるための優れた方法です。起動時にすべてのモジュールをコンパイルするのではなく、オンデマンドでモジュールをコンパイルします。 これにより、開発者は開発サーバーを起動したときにアプリケーションがすぐに実行されていることを確認し、必要なモジュールを段階的にビルドできます。

遅延コンパイルが必要な理由

Rspack 自体は優れたパフォーマンスを備えていますが、モジュール数が非常に多いアプリケーションをビルドする場合、全体のビルド時間は依然として理想的とは言えません。 これは、アプリケーション内のモジュールが `postcss-loader`、`sass-loader`、`vue-loader` などのさまざまなローダーによってコンパイルされる必要があるため、追加のコンパイルオーバーヘッドが発生するためです。

遅延コンパイルを有効にすると、Rspack はリクエストされたエントリポイントと動的インポートモジュールのみをコンパイルします。 これにより、開発起動時にコンパイルされるモジュールの数が大幅に削減され、起動時間が短縮されます。

次のシナリオを考えてみましょう

あなたのチームは、数十ページの MPA アプリケーションを開発しています。 ほとんどの場合、あなたは少数のページでのみ作業し、他のページのコードをビルドする必要はありません。 この場合、遅延コンパイルを有効にして、Rspack がアクセスするページによって参照されるモジュールのみをコンパイルできるようにすることができます。

遅延コンパイルが有効になっている場合、Rspack は「エントリポイント」と「動的インポート」を分割ポイントとして扱います。 例えば

src/a.js
if (someCondition) {
  import('./b.js');
}

a.js をコンパイルすると、Rspack は b.js を空のモジュールとして扱い、まるでコードが書き込まれていないかのように扱います。 b.js にアクセスする必要があるとすぐに、Rspack は b.js モジュールに元のコンテンツを埋め込み、ユーザーがそのコードを書き込んだかのようにします。

Rspack ドキュメントサイトを例にとると、いくつかのページが含まれています。 遅延コンパイルが有効になっている場合、エントリポイントとそれらに依存するモジュールのみがビルドされます。 これにより、起動速度が大幅に向上し、起動時間が 2.1 秒から 0.05 秒に短縮されます。

開発者がサイトの特定のページにアクセスすると、そのページのビルドがトリガーされます。 このビルド時間は、フルビルド時間よりも大幅に短縮されます。

lazy-compilation-compare

使用方法

experiments.lazyCompilation 設定を通じて、Rspack で遅延コンパイル機能を有効にすることができます

rspack.config.js
const isDev = process.env.NODE_ENV === 'development';

module.exports = {
  experiments: {
    lazyCompilation: isDev,
  },
};

現在の遅延コンパイルは webpack の実装と一致しており、**まだ実験段階**であることに注意してください. 一部のシナリオでは、遅延コンパイルが期待どおりに機能しない場合や、パフォーマンスの向上がわずかである場合があります。

より安定した状態を実現するために、さまざまなシナリオで遅延コンパイルの使いやすさを引き続き改善していきます。 使用中に問題が発生した場合は、GitHub Issues からフィードバックをお寄せください。

CSS ビルドの高速化

v0.7 では、experiments.css の内部実装をリファクタリングしました。

CSS 依存関係分析のために、Rust を使用して css-module-lexer を開発しました。これは、CSS または CSS Modules を解析し、それらの依存関係メタデータを返す高性能なレクサーです。

css-module-lexer の統合により、Rspack はより複雑な CSS Modules 構文をサポートできるようになり、その動作は webpack の `css-loader` と一致するようになりました。 たとえば、次の CSS Modules 構文をサポートできます

style.module.css
:local(.parent):global(.child) > ul {
  color: red;
}

リファクタリング前後の CSS 解析プロセスを以下の図に示します

rspack-css-lexer

`css-module-lexer` は、Rspack の `experiments.css` にも大幅なパフォーマンス向上をもたらしました。 パフォーマンステストでは、`bootstrap.css` のビルドパフォーマンスが約 4 倍向上しました。

  • リファクタリング前: ~84 ms (CSS 依存関係の分析 ~71 ms)
  • リファクタリング後: ~25 ms (CSS 依存関係の分析 ~11 ms)

破壊的な変更

Rspack はバージョン 1.0 より前にすべての不安定な API と設定を徐々に削除し、より多くの設定 / API / デフォルトの動作が webpack と一致するようになります.

不安定な JavaScript API の廃止

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#6448rspack#6505 を参照してください.

CSS の @import 規則は、他のすべての規則よりも前に記述する必要があります

Rspack 0.7では、experiments.cssの内部実装を部分的にリファクタリングしました。

リファクタリング後、@importが先頭にない場合、以下のエラーが発生します。この場合は、@importルールを手動で先頭に調整する必要があります。

ERROR in ./src/main.css
  × Module parse failed:
  ╰─▶   × CSS parsing warning: Any '@import' rules must precede all other rules
         ╭─[4:1]
       4};
       5       6 │ @import 'bootstrap/dist/css/bootstrap.css';
         · ───────
       7       8         ╰────

  help:
        You may need an appropriate loader to handle this file type.

builtinsとexperiments.rspackFuture.newTreeshakingの削除

v0.7では、builtins.treeShaking(旧ツリーシェイキング)とexperiments.rspackFuture.newTreeshaking(新ツリーシェイキングスイッチ)の設定が削除され、旧ツリーシェイキング機能は完全にオフラインになりました。

resolve.browserFieldの削除

この設定はresolve.aliasFields = ["browser"]の省略形であり、Rspackは既にresolve.aliasFieldsをサポートしているため、この設定は不要になりました。

experiments.newSplitChunksの削除

この設定は、新しいsplitChunks実装を有効にするために使用されていましたが、Rspackは既にデフォルトで新しいsplitChunks実装を使用しているため、この設定は不要になりました。

snapshotの削除

この設定は、キャッシュ使用時のスナップショット戦略を制御するために使用されていました。Rspackの現在のインクリメンタルリビルドアーキテクチャでは、キャッシュはスナップショットに依存しなくなったため、この設定は不要になりました。

モジュールタイプcssのexportsConventionの削除

この設定は、experiments.cssでCSSモジュールエクスポートの命名規則を制御するために使用されていました。これは、エクスポートを持つモジュールタイプcss/moduleのモジュールにのみ影響します。モジュールタイプcssのモジュールにはエクスポートがないため、この設定は不要です。

SWCを0.91.xにアップグレード

Rustクレートswc_core0.91.xにアップグレードしました。これは、SWC Wasmプラグインのユーザーに影響します。

移行ガイド

SWCプラグインのアップグレード

バージョンv0.7では、Rustクレートswc_core0.91.xにアップグレードされました。 SWC Wasmプラグインのユーザーは、使用されているswc_coreとのバージョンの一貫性を確保する必要があります。そうでない場合、予期しない問題が発生する可能性があります。

詳細については、SWCのドキュメントをご覧ください。

resolve.browserFieldをresolve.aliasFieldsに置き換え

以前にresolve.browserFieldを設定していた場合は、resolve.aliasFieldsに置き換える必要があります。

  • resolve.browserField = trueresolve.aliasFields = ["browser"] に置き換えられます
  • resolve.browserField = falseresolve.aliasFields = [] に置き換えられます

generator.css.exportsConventionの削除

以前にmodule.generator.css.exportsConventionまたはgenerator.exportsConventionmodule.ruleで設定していた場合は、その設定を削除するだけで済みます。

Rsbuild v0.7

Rsbuild v0.7がRspack v0.7と共にリリースされました。詳細については、Rsbuild v0.7の発表をご覧ください。