feat: Improve server error logging

[hamboomger]

Partly resolves #13862.

This PR sanitizes stack trace for server errors by finding the last occurrence of "+page.", "+server.", or "+layout." in the stack trace, and removing everything that comes after that line.

Error logs on the server before:

Error: test
    at load (/Users/hamboomger/apps/selectra/src/routes/admin/(app)/normalize-html/+page.server.ts:2:11)
    at Module.load_server_data (/Users/hamboomger/apps/selectra/node_modules/@sveltejs/kit/src/runtime/server/page/load_data.js:61:41)
    at /Users/hamboomger/apps/selectra/node_modules/@sveltejs/kit/src/runtime/server/data/index.js:62:13
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async Promise.all (index 3)
    at async Module.render_data (/Users/hamboomger/apps/selectra/node_modules/@sveltejs/kit/src/runtime/server/data/index.js:99:17)
    at async resolve (/Users/hamboomger/apps/selectra/node_modules/@sveltejs/kit/src/runtime/server/respond.js:441:17)
    at async Module.respond (/Users/hamboomger/apps/selectra/node_modules/@sveltejs/kit/src/runtime/server/respond.js:327:20)
    at async file:///Users/hamboomger/apps/selectra/node_modules/@sveltejs/kit/src/exports/vite/dev/index.js:525:22

After:

[500] POST /force-error
Error: test
    at load (/Users/hamboomger/apps/selectra/src/routes/admin/(app)/normalize-html/+page.server.ts:2:11)

I also colored the top line red, because why not:

---

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

As for the tests, I couldn't find a way to write Playwrite tests for the server logs. I dug up some similar tests, but they only test the error object itself, not the server log messages.

It seems like you can't easily listen on the server logs in Playwright, so if we really need it, I'd have to intercept the console.log(...) statements with something like this:

  const originalError = console.error;
  console.error = (...args) => {
    globalThis.__collected_errors = globalThis.__collected_errors || [];
    globalThis.__collected_errors.push(args);
    originalError(...args);
  };

• 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: dfb570c

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	Minor

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

[hamboomger]

Please tell me if I should delete the changes from the playground directory 🙂

[svelte-docs-bot]

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

[benmccann]

Can you please update the PR title to more specifically describe how error logging is being improved?

[hamboomger]

@benmccann yes, of course, sorry 😅 I just added some extra context.

[Rich-Harris]

Thank you, this is a huge improvement! I made a few tweaks: added a leading newline, so that the message is padded, and made file paths project-relative. I also changed the heuristic for 'is user code' to 'does it begin with src?' so that things like hooks.server.ts and remote functions are also covered.

(This does assume that the developer hasn't configured kit.files.* to be something else, but a) doing so is deprecated, and b) the worst case scenario is that the stack trace includes some stuff in node_modules.)

We can't do a lot about the stack trace in dev without having access to sourcemaps. Since that's likely to be a nightmare to figure out, given adapters and whatnot, I think we can safely punt on that for now