feat(ssr): support ESM-only dependencies

[aleclarson]

Description

This is a proof-of-concept for compatibility with ESM-only dependencies in Vite SSR.

It needs #3950 and #3951 to be merged first. Therefore, I've squashed those two branches and included them in this PR, so you'll want to look at 6a279e80 to avoid all the git-diff noise.

Caveats:

• The temporary override of require resolution being done in fix(ssr): use tryNodeResolve instead of resolveFrom #3951 is incompatible with Node's ESM loader, so ESM-only dependencies are unaware of resolve.dedupe and mode options. The only way around this is to inject an experimental ESM loader through a CLI flag (see here), which is not ideal, since we really only want to affect module resolution while loading an SSR module, rather than all the time, but maybe that issue can be fixed via temporary injection of the Vite config into the ESM loader.

Other than that, this approach seems to be bullet-proof.

Playground

I've also included an ssr-esm playground, but no automated tests yet. To test it out, do the following:

cd packages/playground/ssr-esm
pnpm install
pnpm serve

Try setting mode: "production" in the Vite config to see the ESM-only package load the incorrect module for its cjs-package dependency, resulting in duplicate instances of cjs-package (one from ./index.js, the other from ./index.dev.js).

---

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

• 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.

[benmccann]

it could be worth expanding this comment to explain why we want to avoid the ESM resolver

[benmccann]

I don't understand this part. It seems to be suggesting that all external imports will be nodeRequired. But if it's an ESM-only module, I believe we should import rather than require it

[benmccann]

Do we want to close this in favor of #5197, which I think would also address the same issue?