Rollupビルドの外部依存設定に `@rails/activestorage` を追加

@rails/activestorage を devDependencies へ移動したことで発生していたRollupのビルド失敗を、external 設定の追加によって解消しました。

背景

@rails/activestorage が devDependencies へ移動したことで、Rollupがバンドル時にこのパッケージをチャンク分割しようとするようになりました。しかし rollup.config.mjs では出力先として output.dir ではなく output.file が指定されており、Rollupがコード分割（chunking）を試みると「output.file 使用時はチャンク分割できない」というエラーでビルドが失敗する状態になっていました。

NPM公開用の設定ファイル rollup.config.npm.mjs では、同パッケージはすでに external に列挙されていたため問題はありませんでした。今回の変更はアセットビルド用の設定ファイルへ同様の設定を追加することで、両設定の整合性を取るものです。

技術的な変更

rollup.config.mjs に external フィールドを追加し、@rails/activestorage をバンドル対象から除外するよう指示しました。

変更前:

export default [
  {
    // ...
    plugins: [
      nodeResolve(),
      commonjs(),
    ]
  }
]

変更後:

export default [
  {
    // ...
    external: [
      "@rails/activestorage"
    ],
    plugins: [
      nodeResolve(),
      commonjs(),
    ]
  }
]

あわせて rollup.config.npm.mjs では、文字列リテラルのクォートがシングルクォートからダブルクォートに統一されました。@rails/activestorage の記述も同様にダブルクォートへ揃えており、機能的な変更は含まれていません。

この設定変更を受け、ビルド成果物である lexxy.js・lexxy.min.js およびそれぞれの圧縮済みファイル（.br・.gz）が再生成されています。

設計判断

external による除外 という最小限のアプローチが採用されました。

output.file から output.dir へ変更してコード分割を許容する方法も技術的には取り得ますが、それは出力構造全体への影響を伴います。今回は @rails/activestorage をバンドルに含める必要がそもそもない（利用側の環境に存在する前提の依存関係である）ため、external で除外することが最も適切な対処です。rollup.config.npm.mjs でも同パッケージが external に列挙されていたことが、この判断の根拠を裏付けています。

まとめ

output.file 指定時のRollupの制約と external 設定の関係を突いた、ピンポイントかつ低リスクな修正です。devDependencies への移動という依存関係の変更がビルド設定に波及するケースとして、Rollupを使うプロジェクトでの参考になる変更といえます。