Generate filename according to bundle file

[jasonkarns]

For rollup configurations that generate multiple bundles, there is a recurring pattern with the visualizer plugin. I want a stats output file for each bundle; and the visualizer settings for each stats file are the same. However, the current visualizer plugin settings require that I duplicate the plugin config for each bundle because the stats filename must be declared for each one.

I propose that the stats filename be determined by the generateBundle hook's filename info. There are a number of different aspects here, but I'll propose the simplest one:

  output: {
    format: 'es',
    file: `dist/foo.js`,
    plugins: [ visualizer() ],
  }

The above configuration should generate: dist/foo.js.stats.html.

I would expect this "automatic" filename logic to:

• respect output.dir
• use output.file as the basename, with .stats.html or .stats.json appended
• (possibly) support a new option "basename" or "suffix" or something that replaces the visualizer filename option such that the stats file is written to: ${output.dir}/${output.file}.${suffix}.${html || json} (suffix would default to "stats")

A spike of this implementation is below, with the caveat that it can only be assigned within the generateBundle hook (as the outputOptions are necessary). So the filename can't be assigned at the top level as it is presently.

filename = path.join(outputOptions.dir || "", `${outputOptions.file}.stats.${json ? "json" : "html"}`)

The biggest benefit is that the generated stats files are conventional in exactly the same way as sourcemaps (side-by-side with the file they accompany, + .stats.html suffix instead of .map). This also allows the visualizer plugin to be configured once at the "top level" of a bundle configuration, instead of manually configuring the filename for every individual output bundle.

[btd]

Thank you for very detailed report. What you are proposing makes sense to me (but not everything you wrote is right still).
I will add to my todo list, i am not sure yet how in plugin context understand that plugin is running as output plugin.

[jasonkarns]

I'll open a quick PR with the changes that I've been successfully using locally. But it doesn't require visualizer to work as an output plugin. (Indeed, visualizer() still needs to be added to the top-level plugins because of the transform hook.)

[btd]

Closing this as described in PR