fix: make illegal server-only import errors actually useful

[Rich-Harris]

fixes #14153. The one part I'm slightly nervous about is manipulating the errors that occur during the secondary build to avoid double-logging, though it's probably okay?

This is a radical simplification from what we had before. It results in consistent errors between dev and prod (no more 'build the app to figure out the import chain'), more readable errors (better formatting, more concise message, no useless stack trace), co-locates code better, is more efficient (instead of walking the entire module graph from the universal entry points, it walks up from a server-only module if/when one is found), and is a lot less code.

One very minor trade-off: it's no longer possible to differentiate between static and dynamic imports. I don't think this matters.

Not require ready to merge yet because FUCKING WINDOWS

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 21650f4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Rich-Harris]

I actually think we can get the import chain in development too, by inspecting the dev server's module graph. Tinkering on that locally

[eltigerchino]

LGTM. Might be good to also have a test for a transitive server import as I noticed that most of the tests are just a direct import.

[eltigerchino]

I wonder if we can easily change this to only match $lib/server/ directories or $lib/server.* files to fix #14069 but I guess that can be its own PR after this one

[Rich-Harris]

ah yeah this should really just add a trailing slash. We don't state anywhere that $lib/server.ts should be considered a server-only module — just this:

You can make your own modules server-only in two ways:

• adding .server to the filename, e.g. secrets.server.js
• placing them in $lib/server, e.g. $lib/server/secrets.js

Unfortunately we do currently regard $lib/server.ts as server-only, so the simple fix would be a breaking change. I think we should fix that in SvelteKit 3 and warn on it in the meantime. Will do it as a separate PR

[Rich-Harris]

Actually I've changed my mind. If we think it's okay to fix #14069 in a patch release then the same is true of $lib/server.ts. Just gonna update .startsWith('$lib/server') to .startsWith('$lib/server/')

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-14155-svelte.vercel.app/