I think this is related to #2076 and #6274.
I agree with the discussions in #6274 (comment) and think that a toast is better here.

Oh, I hadn't noticed that. Are we going to move forward with that?

@btea We discussed about this feature in the team meeting. We agreed to the following points:

• it would be nice to have this feature built in
• the UI should be either toast style (feat: runtime error overlay #6274 (comment)) or Next.js style (below, clicking the button shows the overlay) , whichever easier to implement and less invasive if possible
• we are not sure about the options yet and will discuss later, but that wouldn't block the implementation as adding an option later isn't difficult
• for a richer overlay, we probably want to delegate to Vite devtools, and want to keep the built-in one simple

Okay, thank you for your clear explanation. Will we continue with #6274?

It is fine either.

Based on the above suggestions, a basic implementation has been created.

Do you think the current solution is feasible? And regarding the error messages, do we need to perform detailed conversion processing according to #6274?

I think it would be nice to have the sourcemap support for the runtime error like #6274 has. While #6274 processes the sourcemap mapping on the client side, I think we should do in on the Vite server side so that we don't have to send many data to the browser.

@sapphi-red I noticed that #20916 addressed the issue by forwarding the error message to the server terminal. Should this PR be closed?

#20916 sends the errors to the server but it doesn't show them in the browser. I think it's a different feature.