feat: ssr build using optimized deps

[patak-cat]

Description

Follow up to:

• feat: non-blocking esbuild optimization at build time #8280
• feat: scan free dev server #8319
• feat: default esm SSR build, simplified externalization #8348

This PR removes the need for @rollup/plugin-commonjs for SSR builds, enabling dep optimization using esbuild by default for them.

After this PR, if the user doesn't use optimizeDeps.disabled: 'build' or optimizeDeps.devScan: true then Vite isn't using plugin-commonjs or the esbuild scanner. In the same way we are doing with terser, we could decide in Vite v3 to avoid @rollup/plugin-commonjs as a dependency and ask users to add it to the project themselves if they need it. It isn't a big dep though, so probably not worthy.

There is a new deps cache for SSR. We could discuss if the build cache could be reused, but given that most deps will be externalized, I think a separate cache wouldn't affect performance. It will allow users to avoid busting the cache if there is a conditional change for the config depending on if we are building for SSR.
Given that we have more caches now, this PRs renames them to be more future proof:

• deps
• deps_build
• deps_build_ssr

And the prev processingDeps are now the same as above but with a _temp suffix. About using a flat structure instead of deps/build, we discussed in a previous PR with Anthony and Blu that this structure is easier to work with.

I thought about renaming deps to deps_dev, but I left it as deps because it is shorter and this dir is seen in the browser network tab.

@benmccann @brillout I would need some help with testing and validating here. Tests are passing on Vite's side, but maybe we should expand them.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[patak-cat]

Merging as this could be considered part of the work done in:

• feat: default esm SSR build, simplified externalization #8348

Let's release an alpha so we help the ecosystem test these changes. If you see an issue here, let's discuss it further PRs

[brillout]

I never fully understood how the externalization algorithm worked so I'm not sure I'd be much of a help here.

If CJS will eventually be deprecated, I wonder whether it's "worth it" to test it.

I'd even argue that having a broken CJS support would be a good thing :-). On a more serious note: #8432.

[patak-cat]

@brillout what is going to be helpful is to make vite-plugin-ssr CI pass with the alphas, with the new defaults that don't use the scanner and plugin-commonjs. If there are breaking changes, you can create a vite-3 branch as SvelteKit did and temporarily update vite-ecosystem-ci to use it so we can get everyone green again.

See https://github.com/vitejs/vite-ecosystem-ci/pull/77/files

[brillout]

@patak-dev Will do.