-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Svelte 5: error/warning follow-up tasks #11305
Comments
This was referenced Apr 24, 2024
dummdidumm
added a commit
to sveltejs/svelte.dev
that referenced
this issue
Dec 9, 2024
This establishes a new route `e/[code]` which serves as a stable reference for all of our warning/error codes. All links to warnings/errors from the Svelte compiler/runtime should go through this route in order to have stable references. That way we can move codes between warnings/errors/different pages or even adjust codes without breaking links. Part of sveltejs/svelte#11305
dummdidumm
added a commit
that referenced
this issue
Dec 9, 2024
dummdidumm
added a commit
that referenced
this issue
Dec 9, 2024
Rich-Harris
pushed a commit
to sveltejs/svelte.dev
that referenced
this issue
Dec 9, 2024
* feat: add stable route for all warning/error codes This establishes a new route `e/[code]` which serves as a stable reference for all of our warning/error codes. All links to warnings/errors from the Svelte compiler/runtime should go through this route in order to have stable references. That way we can move codes between warnings/errors/different pages or even adjust codes without breaking links. Part of sveltejs/svelte#11305 * prerender entries * work around Vercel's route limitation * another workaround
dummdidumm
added a commit
that referenced
this issue
Dec 9, 2024
Rich-Harris
added a commit
that referenced
this issue
Dec 9, 2024
* docs: more details for errors/warnings on the site Related to #11305 * Apply suggestions from code review Co-authored-by: Rich Harris <[email protected]> * fix in correct place * tab not spaces * tweaks * fix * Apply suggestions from code review * regenerate --------- Co-authored-by: Rich Harris <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the problem
Just jotting down a few thoughts on follow-ups to #11294, #11302, #11303 and #11304:
finish porting all runtime errors
use blockquote syntax for existing messages — i.e. put
>
before everything that isn't a header. The reason for this is that we can provide excessive detail immediately below the blockquote, but (for example) only show it in the docs. It also enables......overloads. In a few cases we have situations like 'did you mean ?' — short of inventing a convoluted new syntax this sort of thing is trickier to accommodate in markdown. But I think we could get the same benefits by overloading messages — if we have something like this...
...then we could choose which summary message to use based on the function arity. The alternative is to continue having multiple error/warning codes for these situations, but that kinda sucks
sort out the messages themselves — there's lots of weird codes, messages that could be improved, duplicative stuff and so on
add them to the docs
link to the docs from the console
add details to more messages
The text was updated successfully, but these errors were encountered: