fix(remix-dev/vite): start SSR build within plugin

[markdalgleish]

tl;dr: You only need to run vite build now, not vite build && vite build --ssr 🎉

Since we're trying to stabilise the Vite API, I realised that consumers need to stop co-ordinating multiple Vite builds as they're doing today. This is because we're looking at adding support for server bundle shredding (i.e. multiple request handlers, not just one) and RSC, and both of these would mean that we won't know how many builds there will be ahead of time. To handle both of these scenarios, this PR adds a queue where we can push subsequent Vite build processes from within the initial vite build pass.

By the way, after this change I tried running vite build && vite build --ssr and it still works, it's just slower due to the double SSR build.

An alternative approach to this would be to wrap Vite in the Remix CLI (remix vite:build etc., or something similar), but that introduces its own set of complexity since we'd need to forward everything from our CLI to Vite, manage args parsing and validation, keep up to date with Vite CLI API changes etc. I initially went down this road and it started feeling too heavy, so I pivoted to the approach in this PR instead to see how we felt about it. It's nice that we get to continue being "just a Vite plugin", but it's a bit non-standard the way we're achieving it. I'm keen to get some feedback on it.

Todo:

• Confirm that CLI args are passed to the child SSR build (e.g. vite build --assetsInlineLimit <number>)

UPDATE: While this solution is clever, it has some major drawbacks that I'm referring to as the "uncanny valley effect", one example of which is the question @mmachatschek raised below, but this is certainly not the only issue. I've opened another PR with a more traditional solution that addresses these tradeoffs: #8211.

[changeset-bot]

🦋 Changeset detected

Latest commit: c42b31f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@remix-run/dev	Patch
create-remix	Patch
remix	Patch
@remix-run/architect	Patch
@remix-run/cloudflare	Patch
@remix-run/cloudflare-pages	Patch
@remix-run/cloudflare-workers	Patch
@remix-run/css-bundle	Patch
@remix-run/deno	Patch
@remix-run/eslint-config	Patch
@remix-run/express	Patch
@remix-run/node	Patch
@remix-run/react	Patch
@remix-run/serve	Patch
@remix-run/server-runtime	Patch
@remix-run/testing	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mmachatschek]

With the previous setup, one could select different cli args between client and SSR builds (e.g. --sourcemap). how can we achieve the same behaviour of this with a single vite build command?

vite build && vite build --ssr --sourcemap

[hi-ogawa]

@mmachatschek I think users can still customize it using functional config, for example:

import { defineConfig } from "vite";

export default defineConfig((env) => ({
  build: {
    sourcemap: env.isSsrBuild,
  },
}));

I would prefer this form regardless of this PR's change since, in this way, vite.config.ts represents full information of the build instead of needing to check specific flags in scripts.

[markdalgleish]

It was a fun experiment while it lasted, but we're closing this in favour of #8211 where you can find some more explanation for the shift in our approach.

[markdalgleish]

@mmachatschek Thanks for raising that question by the way, it helped flesh out a big tradeoff with this approach.