fix: don't consider ids with npm: prefix as a built-in module

[marvinhagemeister]

Description

We're working on revamping our Deno vite plugin and noticed that any specifier starting with npm: is not being passed through the plugin system. Those kind of specifiers are frequently used when using packages from JSR in Deno, without going through the jsr npm registry adapter.

After a bit of debugging it turns out that this code here makes it so that every npm: specifier is treated as a built-in module:

vite/packages/vite/src/node/utils.ts

Lines 101 to 102 in 3f7598c

	// Supported by Deno
	const NPM_BUILTIN_NAMESPACE = 'npm:'

vite/packages/vite/src/node/utils.ts

Lines 136 to 145 in 3f7598c

	export const nodeLikeBuiltins = [
	...nodeBuiltins,
	new RegExp(`^${NODE_BUILTIN_NAMESPACE}`),
	new RegExp(`^${NPM_BUILTIN_NAMESPACE}`),
	new RegExp(`^${BUN_BUILTIN_NAMESPACE}`),
	]
	export function isNodeLikeBuiltin(id: string): boolean {
	return isBuiltin(nodeLikeBuiltins, id)
	}

This is not correct as Deno doesn't ship with npm: modules built-in. It supports loading these specifiers from the npm registry instead. Consequently, the fix is pretty simple: Don't treat npm: specifiers as built-in modules. With that change npm: specifiers are passed through the plugin system again.

[sapphi-red]

I think we should keep the npm: check for this call, otherwise import 'npm:foo' would fail to resolve in the config.

vite/packages/vite/src/node/config.ts

Lines 1996 to 2001 in 9ecc5f9

	// With the `isNodeBuiltin` check above, this check captures if the builtin is a
	// non-node built-in, which esbuild doesn't know how to handle. In that case, we
	// externalize it so the non-node runtime handles it instead.
	if (isNodeLikeBuiltin(id)) {
	return { external: true }
	}

[marvinhagemeister]

Good point, hadn't considered the configuration transpilation pass. Sounds like we need to split this up. I've updated the PR to add the npm: case to the config transpilation. That way both scenarios work.