svelte
svelte copied to clipboard
feat: provide better error messages in DEV
Today, Svelte 5's error message is a bit lacking. This PR aims to make the error messages much better in DEV. Previously, you'd get given the error message and some stack that likely meant nothing. With this PR, you now get the component stack too along with a clearer message. At also lets you know if the error occurred in different types of effect.
- We now name the effect functions, so they're clearer in the stack trace as to what they are
- We filter out Svelte internal functions from stack traces, so it makes it easier to see what is likely causing the issue
- We provide the component stack up until when the error occurred so you can what components we used in the lead up the error
- We now avoid retrying hydration or showing a mismatch for user errors. We keep the hydration mismatch warning for actual mismatches.
- Fixed a bunch of subtle things I encountered when working on this.
🦋 Changeset detected
Latest commit: 59711592ea926597dc35c67fcbe542fa9bc89e58
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 1 package
| Name | Type |
|---|---|
| svelte | 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
It would be nice if we could just replace the new error stack with the original rather than including the original in the message, since stack traces are given special treatment by devtools (e.g. respecting sourcemaps, excluding things as specified by x_google_ignoreList). The exact treatment differs from browser to browser, but this is what I'm seeing in the playground in Firefox — it's a useless wall of text:
If I do new_error.stack = error.stack instead of adding the stack to component_stack_string then I get this instead, which is much better:
Unfortunately that kills the error message in Chrome, so there's more finessing required.
Then again: if we have a working stack trace, do we need the component tree as well? What additional information does it provide? (Also, it's currently misidentifying the component responsible for the error, for me — it's blaming the component's parent.) I'm not clear to me what we gain by calling handle_error.
@Rich-Harris I addressed the issues you mentioned. This PR wasn't finished yesterday when you reviewed it and it had some bugs and missing pieces still yet to do. The stack traces now properly work with sourcemaps.