fix(ssr): externalize network imports during ssrLoadModule

[hi-ogawa]

Description

• Closes running vite.ssrLoadModule causes error when using ESM CDN for example (esm.sh) #15143

I haven't fully tested yet, but one cause of the issue is that ssr nodeImport is trying to tryNodeResolve on external url. I'll experiment this further and adding tests etc...
(Now I added a test, but the way I did is probably overkill e.g. esm.sh dependence, experimental flag, etc... This was a easy way to verify locally, so I started with this. I would appreciate any suggestions on how it should be tested.)

Additional context

I made this repro https://github.com/hi-ogawa/repro-vite-ssr-network-imports to understand the current state. It looks like transformRequest(... { ssr: true }) is preserving network imports properly but ssrLoadModule is failing because of nodeImport/tryNodeResolve.

Network import is experimental on NodeJS, so users would need to enable --experimental-network-imports flags manually if they need this feature https://nodejs.org/api/esm.html#https-and-http-imports. (I wonder if there's any Vite-based SSR framework on Deno. if there is one, then I feel more people would be blocked by this.)

I'm not sure about the actual usefulness of network import feature myself, but just letting the external url go through during ssr dev seems reasonable as it would also align with other places such as import analysis during build:

vite/packages/vite/src/node/plugins/importAnalysisBuild.ts

Lines 339 to 342 in 06de8f0

	// skip external / data uri
	if (isExternalUrl(specifier) || isDataUrl(specifier)) {
	continue
	}

Additionally, there is an issue on Vitest vitest-dev/vitest#4949, but since vite-node doesn't use ssrLoadModule directly, I'm suspecting that the cause is different and Vite-side fix is not relevant for Vitest.

---

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, especially the Pull Request Guidelines.
• 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).
• Update the corresponding documentation if needed.
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[omridevk]

@hi-ogawa
My use case is that I want to implement microfrontend using HTTP imports, this works fine in the browser, but I want to support SSR as well, which I will need to support HTTP import on node js as well.

[omridevk]

@hi-ogawa
Oh and thanks a lot for the PR

[omridevk]

@hi-ogawa
Maybe for testing we can setup a local static asset that just returns a js file with a variable

As we cannot use external urls that we do not have control over for testing, esm.sh may go out of business and this test will fail.

[omridevk]

@hi-ogawa also verified your fix locally and it seems to solve the error, great work :)

[hi-ogawa]

@omridevk Thanks for confirming the fix on your end!

Regarding the tests, actually there was esm.sh dependency in other places in the past, but it looks like they was just removed recently due to test flakiness #14684 Thanks for the suggestion. For the purpose of the review, I think this is okay, but I'll think about avoiding external network request here.

[bluwy]

Great test! And this looks like the right spot to add the check.

I know there are Vite plugins that handles URL imports, but I think they should be resolving those import paths to a safe id / virtual id, so the nodeImport never hits for those imports. So might be safe there.