fix: import.meta.url should not throw

[benmccann]

Description

SvelteKit, like many other Vite-based frameworks, executes user code on both the server and client. The typical way that SvelteKit users run code only on the client would be to put that code in an if (!import.meta.env.SSR) check or Svelte's onMount function so that it is only executed on the client.

Vite currently throws an exception if import.meta.url is encountered on the server. This is happening even if the code is never run and even if the code isn't in the final bundle because the bundler knows it's never run and removes it via dead code elimination / tree shaking.

There is other code like window and navigator that similarly cannot be run on the server. In those instances, we don't throw an exception if those are contained in the SSR build. I don't think it's really necessary to treat import.meta.url more strictly than window or navigator. If we did want to add some check it'd be better to find a way to do it in the end like in closeBundle after dead code elimination / tree shaking happens, but I'm not quite sure the API would allow an easy way to do that and I don't really see that it's needed.

Additional context

This seems to come up a lot when people try to use SvelteKit + wasm. E.g. sveltejs/kit#1896

---

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.
• Read the Pull Request Guidelines and follow the Commit Convention.
• 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.

[bluwy]

This looks fine to me. I suppose a bonus is if we can make a Proxy to give helpful errors in runtime instead

[matthewp]

Thanks for fixing this! We had been running into this in Astro as well and were planning on submitting a patch.