-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
chore(ssr): show the user land ssr error stack #12714
base: main
Are you sure you want to change the base?
Conversation
|
@brillout cc |
Love it 😍. I wonder whether the errors can be further bundled? In principle, I believe there are only two errors: one while executing (FYI: if vite-plugin-ssr encounters an error, then vite-plugin-ssr tries to render the error page which may encounter another error. That's why there can be up to two errors for a single HTTP request.) |
Yeah. We could minimize the error output, you can check the updated description. I think it's good enough for now |
Nice, very pretty. So there is no way to get rid of the redundant first error? Little nitpick: how about the following?
|
Ah I found it's possible. See https://user-images.githubusercontent.com/102238922/229852488-34f993ab-c090-47ca-86bf-163beb51a173.png
Not sure about this. Not much difference between this and Any idea? @bluwy @patak-dev |
Yeah I think we should keep the current error messages style, the file path at the end makes it easier to follow. |
I'd argue that "server-side" is clearer than "SSR". Not only doesn't everyone know what "SSR" means but also "SSR module" is actually a misnomer. SSR = Server-side Rendering while a "SSR module" may have nothing do to with SSR (e.g. pre-rendered SSG apps). As for "executing" VS "evaluating": I think for people who aren't fluent in computer/English language, "executing" is more familiar than "evaluation". ("Evaluating" is quite a computer science term.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A question below. If you have an example project to test the errors you can share, that'll be great too 🙏 Trying to understand how the flow of this works.
|
||
// only log the root url's error | ||
if ( | ||
errorDepsStack.filter((dep) => !dep.startsWith('virtual:'))[0] === url |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this is filtered by virtual:
? I'm not sure if it's right to handle virtual:
specifically.
Also, to confirm, is logging the root check helps deduplicate errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Ah I may make a mistake here since
virtual
module should be in the error stack - It will prevent the same error from outputting multiple times in a root-leaf path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the virtual:
filtering logic again, the error would not propagate to the virtual module(not sure why), so we have to filter it. @bluwy
e.g urlStack
is
['virtual:vite-plugin-ssr:importUserCode:server',
'/renderer/_error.page.tsx',
'\x00react/jsx-dev-runtime']
The error-catched url would never be virtual:vite-plugin-ssr:importUserCode:server'
Relevant to the repo: #12714 (comment). |
Description
refs #12631 (comment)
Before PR:
After PR:
Additional context
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123
).