RFC: Add flag when emitting assets to not emit files that are not referenced in the output

[lukastaegert]

Feature Use Case

Currently, it is possible that an asset is emitted, but the usage of that asset is removed by tree-shaking. E.g. in the original code we have something like

import asset from './asset.svg';

if (COMPILER_FLAG) {
  const image = document.createElement('img');
  image.src = asset;
  document.body.appendChild(image);
}

Now one plugin resolves asset as import.meta.ROLLUP_FILE_URL_abc123 and another plugin replaces COMPILER_FLAG with false. In that scenario, the file would still be emitted but it is not referenced.

Feature Proposal

Add a new property needsCodeReference: boolean to EmittedAsset. If it is set to true, then the asset is only emitted if at least one corresponding import.meta.ROLLUP_FILE_URL_referenceId can be found in the emitted chunks.

If the flag is not provided, it is treated as false for backwards compatibility.

See also #4761 for another issue that is addressed by this.

Note: Assets can be deduplicated if they have the source. In that case, several reference ids can reference the same asset. In that scenario, the usage of one of the reference ids is of course enough for the asset to be emitted.

[rollup-bot]

This issue has been resolved via #4805 as part of rollup@3.11.0. You can test it via npm install rollup.

[stabas]

But is there a way/option to emit assets that are not referenced?

[lukastaegert]

Of course, just do not add needsCodeReference when emitting them. See https://rollupjs.org/plugin-development/#this-emitfile for how to emit files in general.

[stabas]

I'm using astro for my project, which uses vite for build. How do I configure "needsCodeReference" in rollout options?

astro.config.mjs

...
vite: {
    build: {
        rollupOptions: {
            output: {
                ...
            }
        }
    }
}
...

[lukastaegert]

Only the plugin emitting the asset can configure it. In order to emit assets yourself, you need to write a plugin. But outside a plugin, you would not have access to the file reference id anyway, so this whole thing only makes sense in a plugin context.