Async Vite plugins

[bluwy]

Update: This is now supported in Vite 3 (#8574)

Proposal

Allow passing promises to the plugins config.

Changing the plugins type to: (Plugin | Plugin[] | Promise<Plugin | Plugin[]>)[]

Reason

For plugins that require running async code on initialization, e.g. importing a config file, not having async support makes it hard to arrange the code/logic of the plugin. The common workaround is to run the async code during the config or configResolved hook, though it makes it hard to pass the async result around.

Example:

export function myPlugins() {
  let my_config
  return [
    {
      name: 'foo',
      enforce: 'pre',
      async config() {
        my_config = await load_my_config()
      }
    },
    bar(my_config) // needs the config
  ]
}

Code organization-wise, being able to asynchronously load the config on initialization phase simplifies the flow too.

Alternatives

1. A solution is to use Object.assign for the my_config to preserve the reference, though it isn't as elegant and has caveats, like being able to access my_config after we know the config hook has ran.

2. Use top-level await when initializing plugins:

{
  plugins: [await myPlugin()]
}

Though this only works in ESM.

Notes

esbuild's plugin object has a setup property that can be an async function:

const esbuildPlugin = {
  name: 'foo'
  async setup(build) {}
}

[patak-dev]

I like the idea. Option 2 looks nice, but it also isn't the same because awaiting will be sequential or users will be forced to use Promise.all which will make the config less readable.
Maybe another alternative is to provide an awaitPlugins(...) utility, but at that point, why not directly implement the feature cleanly in core and accept Promises in the plugins config?

Do you know what was the rationale to avoid this in Rollup? (@lukastaegert, in case you are around maybe you recall a discussion, I searched the rollup issues but I could find one)

[lukastaegert]

There was just not enough demand to add this. One thing to consider is that the options hook should probably no longer receive the original config but a config where all plugins are resolved, and we probably should disallow adding async plugins in the options hook so that e.g. plugins can easily check which other plugins are installed and this is not a breaking change.

[patak-dev]

Thanks for your input. And resolving inside options seems like a sensible restriction. @bluwy if this ends up being added to Vite, maybe it is a good idea to also do a PR to rollup later. Users could still await the hooks with a helper, but I think it would be good that both Vite and Rollup works the same here.

[bluwy]

Yeah having parity for Vite & Rollup would be nice long term. I think there wasn't much of a demand in Rollup before as Rollup plugins are usually created as a single object only, and the Rollup plugins option only accepts an array without flattening.

Good point about Promise.all too. If more plugins are async, they should run in parallel in most case.

[sapphi-red]

Similar to Alternative 2, it could be done like this:

export default defineConfig(async () => ({
  plugins: [await myPlugin()]
}))

But allowing promise in plugins looks great to me.

[bluwy]

I also realized that after submitting the proposal 😬 so it could work in CJS too, but patak brought up a good point where ideally we would do Promise.all so that they are created in parallel.