Rollup 4への移行
これは、Rollup 3からRollup 4に移行する際に遭遇する可能性のある最も重要なトピックのリストです。破壊的な変更の完全なリストについては、
を参照することをお勧めします。以前のバージョンからの移行方法については、下記を参照してください。
前提条件
少なくとも Node 18.0.0 を実行し、すべての Rollup プラグインを最新バージョンに更新してください。
大規模な設定の場合は、最初に rollup@3.29.4 に更新し、設定にstrictDeprecationsオプションを追加して、発生するエラーをすべて解決することをお勧めします。これにより、Rollup 4で削除された可能性のある機能に依存していないことを確認できます。プラグインにエラーがある場合は、プラグインの作成者にお問い合わせください。
一般的な変更点
Rollupには、プラットフォームとアーキテクチャがサポートされている場合に、オプションの npm 依存関係として自動的にインストール（および削除）されるネイティブコードが含まれるようになりました。より正確には、RollupにはoptionalDependenciesのリストがあり、それぞれが特定のosとcpuでのみインストールされます。システムがサポートされていない場合は、Rollupの起動時にプラットフォームとアーキテクチャに関するエラーメッセージが表示され、サポートされているプラットフォームとアーキテクチャのリストが提供されます。その場合は、プラットフォームに依存しないドロップイン代替として、代わりに@rollup/wasm-nodeを使用できます。
ブラウザビルド（NPMの@rollup/browser）は、WASMアーティファクトにも依存するようになり、これも提供する必要があります。Viteでブラウザビルドを使用している場合は、optimizeDeps.excludeに"@rollup/browser"を追加する必要があります。そうしないと、npm run devが.wasmファイルへの無効なパスで失敗します（vitejs #14609も参照）。それ以外の場合は、特に操作しなくても動作するはずです。
それ以外に、明らかな変更点として、Rollupが古いbase16ハッシュの代わりに、ファイル名でURLセーフなbase64ハッシュを使用するようになりました。これにより、ハッシュの安全性が向上しますが、技術的な理由からハッシュの長さが最大22文字に制限されることを意味します。
CLIアプリをバンドルする場合、Rollupは、出力のformatがesまたはcjsの場合、エントリファイル内のshebangコメントを自動的に保持するようになりました。以前は、プラグインを介してコメントを追加する必要がありました。
最後に、無効なアノテーション位置に関する新しい警告が表示される場合があります。Rollupは、無効な場所にあるため解釈できない@__PURE__または@__NO_SIDE_EFFECTS__コメントを検出した場合に警告を表示するようになりました。これらの警告は、デバッグを支援するためのものです。警告を非表示にするには、--filter-logs CLIオプションを使用できます。
設定の変更点
Rollup 3ですでに非推奨となっていた一部のオプションが削除されましたが、ここでの主な変更点は、acornオプションとacornInjectPluginオプションが使用できなくなったことです。これは残念ながら、サポートされていない構文のプラグインを追加できなくなったことを意味します。需要に応じて、SWCパーサーがそれをサポートするため、JSX構文を再度サポートすることを検討しています。
プラグイン API の変更点
重要な変更点は、this.resolve()がデフォルトでskipSelf: trueを追加するようになったことです。つまり、resolveIdフックからthis.resolve()を呼び出すと、別のsourceまたはimporterを使用しない限り、このフックは、このプラグインまたは他のプラグインからのネストされたthis.resolve()呼び出しによって再度呼び出されません。これは、意図しない無限ループを防ぐためのほとんどのプラグインに対する合理的なデフォルトであると考えています。以前の動作を取得するには、手動でskipSelf: falseを追加できます。
もう1つの重要な変更点は、Rollupのウォッチモードが、プラグインloadフックを介してロードされたファイルのIDを監視しなくなったことです。したがって、これは主に「仮想」ファイルに影響します。この場合、変更のためにハードドライブの場所を監視することは、実際には意味がありません。代わりに、loadフックを使用するプラグインが、loadフックを処理するために、依存するすべてのファイルに対して手動でthis.addWatchFile()を呼び出す必要があります。
プラグインがインポートアサーションを処理する場合、resolveIdフックなどの場所では、JavaScriptの機能も名前が変更されたため、assertionsがattributesに置き換えられていることに注意してください。また、インポート属性の抽象構文ツリー表現は、ESTree仕様に再び従います。
プラグインから警告を発行する場合は、buildStartフックでoptions.onwarn()を呼び出すことはできません。代わりに、this.warn()またはoptions.onLog()を使用します。
Rollup 3への移行
これは、Rollup 2からRollup 3に移行する際に遭遇する可能性のある最も重要なトピックのリストです。破壊的な変更の完全なリストについては、
を参照することをお勧めします。Rollup 1以前のバージョンから移行する場合は、
も参照してください。
前提条件
少なくとも Node 14.18.0 を実行し、すべての Rollup プラグインを最新バージョンに更新してください。
大規模な設定の場合は、最初に rollup@2.79.1 に更新し、設定にstrictDeprecationsオプションを追加して、発生するエラーをすべて解決することをお勧めします。これにより、Rollup 3で削除された可能性のある機能に依存していないことを確認できます。プラグインにエラーがある場合は、プラグインの作成者にお問い合わせください。
設定ファイルの使用
設定ファイルとしてESモジュール、つまりimportとexport構文を使用する場合は、Nodeが設定をESモジュールとしてロードするようにする必要があります。
これを確実にする最も簡単な方法は、ファイル拡張子を.mjsに変更することです。設定ファイルも参照してください。
- ネイティブNode ESモジュールを使用する場合、特に
package.jsonファイルを単純にインポートすることはできません。
__dirnameを使用して現在のディレクトリを取得することはできません。
ネイティブNode ESモジュールを使用する場合の注意点に、これらの処理方法の代替案がいくつか記載されています。
または、--bundleConfigAsCjsオプションを渡して、以前のロード動作を強制できます。
--configPluginオプションを使用すると、Rollupは設定を実行する前に、設定をCommonJSの代わりにESモジュールとしてバンドルするようになります。これにより、設定からESモジュールを簡単にインポートできますが、ネイティブESモジュールを使用する場合と同じ注意点があります。たとえば、__dirnameは機能しなくなります。繰り返しますが、--bundleConfigAsCjsオプションを渡して、以前のロード動作を強制できます。
変更されたデフォルト値
({
makeAbsoluteExternalsRelative: true,
preserveEntrySignatures: 'strict',
output: {
esModule: true,
generatedCode: {
reservedNamesAsProps: false
},
interop: 'compat',
systemNullSetters: false
}
});js
ただし、一般的に、新しいデフォルト値は推奨される設定です。詳細については、各設定のドキュメントを参照してください。
- その他の変更されたオプション
output.banner/footer/intro/outroはチャンクごとに呼び出されるため、パフォーマンス負荷の高い操作は実行しないでください。entryFileNamesおよびchunkFileNames関数は、modulesを介してレンダリングされたモジュール情報にアクセスできなくなり、含まれるmoduleIdsのリストのみにアクセスできるようになりました。
output.preserveModulesおよびentryFileNamesを使用する場合、[ext]、[extName]、および[assetExtName]ファイル名プレースホルダーを使用することはできません。また、モジュールのパスは自動的にファイル名に先頭に追加されなくなりましたが、[name]プレースホルダーに含まれるようになりました。
CommonJS 出力の動的インポート
デフォルトでは、cjs出力を生成する場合、Rollupは外部、つまりバンドルされていない動的インポートを、出力のimport(…)式として保持するようになりました。これは、Node 14以降のすべてのNodeバージョンでサポートされており、生成されたCommonJS出力からCommonJSモジュールとESモジュールの両方をロードできます。古いNodeバージョンをサポートする必要がある場合は、output.dynamicImportInCjs: falseを渡すことができます。
全体的な出力生成フローが再設計されました。新しいプラグインフックの順序については、出力生成フックのグラフを参照してください。おそらく最も顕著な変更点は、banner/footer/intro/outroが、最初の一回だけではなく、チャンクごとに呼び出されるようになったことです。一方、augmentChunkHashは、ハッシュが作成されるときにrenderChunkの後に評価されるようになりました。
ファイルハッシュがrenderChunk後のファイルの実際のコンテンツに基づいて生成されるようになったため、ハッシュが生成される前に正確なファイル名を知ることができなくなりました。代わりに、ロジックは1tPrXgE0のような形式のハッシュプレースホルダーに依存するようになりました。つまり、renderChunkフックで利用可能なすべてのファイル名にはプレースホルダーが含まれる可能性があり、最終的なファイル名に対応しない可能性があります。ただし、これらのファイル名をチャンク内で使用する予定であれば、RollupがgenerateBundleが実行される前にすべてのプレースホルダーを置き換えるため、これは問題になりません。
必ずしも破壊的な変更ではありませんが、renderChunkでインポートを追加または削除するプラグインは、このフックに渡される対応するchunk情報も更新する必要があります。これにより、他のプラグインがチャンクを自分で解析する必要なく、正確なチャンク情報に依存できるようになります。詳細については、フックのドキュメントを参照してください。