Replace `$ vite build && vite build --ssr` with `$ vite build` + enable plugins to add build step

Clear and concise description of the problem

We want to build deploy plugins, e.g. vite-plugin-cloudflare-workers, vite-plugin-vercel, and vite-plugin-deno-deploy.

Currently, the user would need to:

// package.json
{
  "scripts": {
     "build": "vite build && vite build --ssr && vite-plugin-cloudflare-workers build"
  }
}

Suggested solution

// package.json
{
  "scripts": {
     // Automatically runs all three build steps:
     // 1. client bundling
     // 2. SSR bundling
     // 3. custom build step (defined by the plugin)
     "build": "vite build",
  }
}

// vite.config.js
import cloudflareWorkers from 'vite-plugin-cloudflare-workers'
export default {
  plugins: [ cloudflareWorkers() ],
  server: './path/to/server.js'
}

Additional context

There is an increasingly number of deploy environments.

• Deno Edge (which supports Vite apps)
• Supabase Functions
• AWS Lamda
• AWS EC2
• Cloudflare Workers
• Netlify Functions
• Vercel
• …

This ticket enables deploy plugins which in turn enables deeper collaboration between SSR frameworks.

Eventually it is the deploy providers who will maintain these plugins. (Like how Cloudflare Workers took over miniflare.)

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that request the same feature to avoid creating a duplicate.

[antfu]

writeBundle closeBundle parallels executing

I agree this is something limiting the ecosystem to grow and innovate. And we should figure out a better way to improve it. While changing it to complete sequential will hurt the performance and probably be a significant breaking change to the ecosystem. I’m thinking maybe we could have it per-plugin level control of whether those plugins should be executed parallel or sequential. We might need to figure out a good design of how we could express it by extending the current API.

Multiple builds in vite build

In general, I am against doing this. Even if it can be possible, I would personally think it’s a bit anti-pattern. Vite as a front-end tool is mainly for building the client app, given its pretty low-level, meta frameworks calls build() from vite programmatically would assume it only performs one build. Frameworks like VitePress or Vitest will reuse the vite.config.js. Allowing a plugin to change its behavior of it is a bit risky for me.

I think multiple builds should be handled by upper-level frameworks to call Vite programmatically (multiple times at different timing), just like how we do it in many frameworks now. If we really want to rescue the CLI from Vite, I guess we could introduce a separate command like vite pack, but that would be a different story.

[antfu]

RFC here: https://github.com/vitejs/vite/discussions/9442 (solving the limitation of writeBundle closeBundle in general). I am still leaning to against multiple builds in vite build.