Remove svelte/ssr resolving

[benmccann]

sveltejs/svelte#6743 is a better solution to this problem

[dominikg]

we need to update peer dependency on svelte to the version that adds the export map and I hope we can keep the current tests instead of removing them. They should still pass with the new solution

[Conduitry]

Svelte 3.43.0 has been released with the new export map entry, so we can now try this out for real.

[bluwy]

@benmccann We need to update the root package.json's svelte version as well since the pnpmfile enforces the same svelte version based on that. So technically the tests are still running 3.42.x.

We would also want to remove the ssr.noExternal handling here:

vite-plugin-svelte/packages/vite-plugin-svelte/src/utils/options.ts

Lines 290 to 303 in f112d8b

	// add svelte to ssr.noExternal unless it is present in ssr.external
	// so we can resolve it with svelte/ssr
	if (options.isBuild && config.build?.ssr) {
	// @ts-ignore
	if (!config.ssr?.external?.includes('svelte')) {
	noExternal.push('svelte');
	}
	} else {
	// for non-ssr build, we exclude svelte js library deps to make development faster
	// and also because vite doesn't handle them properly.
	// see https://github.com/sveltejs/vite-plugin-svelte/issues/168
	// see https://github.com/vitejs/vite/issues/2579
	svelteDeps = svelteDeps.filter((dep) => dep.type === 'component-library');
	}

but we could do it in a separate PR as this should also work as is. The changes in #166 can also be reverted, and refactored a bit to simplify things.

[bluwy]

Since Vite can't resolve svelte to the node exports, I wonder if we should revert this file change, and swap out svelte/ssr to svelte, so that we "help" Vite out to resolve it. IIRC this.resolve, which uses the resolver plugin has support for exports map, so it should work. But I could completely wrong.

If so, I think we should left using svelte/ssr at the meantime

[bluwy]

@benmccann Nevermind, tested this and it doesn't work