Document how to have different SSR vs browser build config

[Conduitry]

Describe the problem

Having (for example) different build targets for the server and browser builds is currently possible, but not intuitive.

The Vite conditional config docs mention an ssrBuild flag that gets passed into the function, but for us this is currently always false because, at that point, Vite doesn't know that the first build is going to be an SSR one unless we run vite build --ssr.

Another possibility is to write a one-off plugin in vite.config.js after the sveltekit() one that has a config callback that checks config.build.ssr and returns the overriding configuration as appropriate.

Either way, there's a further gotcha that there is only a single build in development mode, and it is not told it is in SSR mode (either with configEnv.ssrBuild or config.build.ssr). If you want to do browser-only transpilation, for example, you will need to forego it in development, and check at build time that this is a production build and that it is not an SSR build before specifying your custom config.build.target.

Describe the proposed solution

The problem here is not so much a "draw the rest of the owl" one as a "figure out where to even draw the owl".

Alternatives considered

If we update the templates to use vite build --ssr, then we can rely on the build-time ssrBuild flag having the right value. Rich didn't like specifying --ssr when we're actually doing both builds (or all three, if you have a service worker).

In this case, we'd still have the only-one-build-in-dev-and-it's-not-marked-as-SSR issue, but at least that's already sort of documented on Vite's side.

I don't think switching to --ssr would remove the need to document this on SvelteKit's side anyway, though, not least because people who'd already created their apps wouldn't have it set.

Importance

nice to have

Additional Information

For me, this came up in the context of wanting to specify different build.target values for my SSR and browser builds. I wanted to be able to transpile for Safari 13 on the browser, but I also wanted to be able to use top-level await on the server, which is not transpilable to that target.

[ccdexcom]

@Conduitry This would be great to have and would help bring some support to targets, especially with #11688 merged. You mentioned that you have a workaround for separate targets per ssr vs browser but that was for SvelteKit 1. From the sounds of your comment an inline vite plugin wouldn't work for SvelteKit 2? Documentation would be great but if you have any tips in the meantime on how this would be possible with SvelteKit 2 it would be great to hear them.

If I understand the landscape correctly, altogether this doesn't totally fix #12 but would give SvelteKit a decently strong story for leaning on some transpilation support by using default vite targets (again, especially with #11688 merged).

[Conduitry]

No, it appeared to still work in Svelte v2. The relevant config was basically:

export default {
	plugins: [
		sveltekit(),
		{
			config(config, { command }) {
				if (command === "build" && !config.build?.ssr) {
					// Override config for production builds for the browser.
					return { build: { target: [...] } }
				}
			},
		},
	],
}

which lets you override build config just for production builds for the browser. A single build both for the browser and the server appeared to be unavoidable in dev mode.