feat: spa option, preview and dev for MPA and SSR apps

[brillout]

Description

This fixes $ vite preview and $ vite dev for SSR and MPA apps.

This PR enables users and frameworks to set config.isSPA = false to disable SPA catch-all routing.

The docs added by this PR include a description of what "SPA catch-all routing" means.

It supersedes these previous PRs:

• feat: server.htmlEntryPoint config option #4640
• fix: $ vite preview 404 handling #7665
• feat: option to disable SPA catch-all #8061

And fixes these issues:

• Remove assumptions around having an index.html that are incompatible with SSR #7631
• Allow disabling spa middleware #5720

Additional context

I decided against config.appType: spa | ssr | mpa because many frameworks blur the line between ssr and mpa. For example, vite-plugin-ssr 0.4 allows the user to implement SSR as well as MPA apps. It also allows the user to have one SSR page while the rest is MPA; it's then not clear whether the app type is ssr or mpa. Many other frameworks, such as Nuxt, also blur the line between SSR and MPA.

Thus I believe having only two modes "SPA" or "not SPA" is the way to go.

I'm fairly confident this PR is in a good state and can be merged as-is on a high-level (edit). (But happy to be shown wrong.)

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[antfu]

A bit nitpicking here, I personally don't feel the isSPA name convention matches with the rest of the configs. Maybe simply spa: false?

[patak-dev]

We talked about the PR in today's team meeting. We're worried about making Vite preview ever more complex to accommodate future requirements from users like vite-plugin-ssr. We still think that a spa option (I agree with Anthony's rename request) is a necessity given current hardcoded assumptions in Vite (independent of the preview changes).
So let's move forward with the PR in v3, but frameworks using vite preview instead of a wrapper needs to understand that future features need to be done in middleware. It is out of the scope of Vite to keep augmenting vite preview to support other requirements.

[brillout]

I've updated the PR and I believe it resolves all discussions.

I've refactored how we document this: the documentation now lives under Guide - SSR which I believe to be a more natural fit.

We talked in today's meeting about transformIndexHtml. We should document that this hook isn't called during SSR.

This is somewhat documented at https://vitejs.dev/guide/ssr.html#setting-up-the-dev-server and since the docs now live on that same page, I believe it's enough.

We're worried about making Vite preview ever more complex to accommodate future requirements from users [...] but frameworks using vite preview instead of a wrapper needs to understand that future features need to be done in middleware

I agree and this is actually what this PR is about: getting Vite's internal SPA assumptions out of the way in order to uncouple Vite from user middlewares.

Telefunc now also adds its RPC middleware to the development and preview servers and it works. I believe that, after this PR, things will be flexible enough to accommodate for all kinds of needs. Some minor tweaks may be needed, but nothing fundamental AFAICT. And, yes, for unreasonable requirements we can answer: write your own CLI.

[benmccann]

Awesome! Thanks for driving this and seeing it through. I'm really excited about it!

[brillout]

Alright, I've applied all suggestions. Let me know if I missed something. Also feel free to directly push to the PR.

Awesome! Thanks for driving this and seeing it through. I'm really excited about it!

I'm glad you're excited about this. Thank you both for your helpful reviews.

[brillout]

This will likely by superseded by #8438.