feat: runtime error overlay #6274

arbassett · 2021-12-27T18:00:35Z

Description

Fixes #2076

To add support for runtime error overlays using vites built in overlay.

it is currently possible to use create-react-app's react-error-overlay in vite but this experience is subpar to how server errors are currently handled

Additional context

This works as a base impetration but i would love to get some feedback on potential addition features and unknowns.

Collapsing React's error stack
- potentially the same for vue. i've never worked with vue before so I'm unfamiliar to how errors are handled
- Should we provide a api for plugins to extend this so we don't have to handle errors for every possible framework ie import.meta.error
How should multiple errors be handled
- Should we show multiple overlays at the same time an require multiple clicks from the user
- Should be collect multiple errors and provide a button to toggle between them
Should the user be able to follow the stack trace down with sources
Should users be able to view the error in source and compiled

vite.runtime.overlay.draft.mp4

What is the purpose of this pull request?

Bug fix
New Feature
Documentation update
Other

Before submitting the PR, please make sure you do the following

Read the Contributing Guidelines.
Read the Pull Request Guidelines and follow the Commit Convention.
Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
Ideally, include relevant tests that fail without this PR but pass with it.

arbassett · 2021-12-27T18:08:10Z

~~I'm expecting some tests to break~~

got them fixed

arbassett · 2021-12-30T02:12:17Z

updated demo showing off promise rejection and more test cases

vite.runtime.overlay.draft.v2.mp4

as a fun aside I was enjoying having a runtime overlay while developing the overlay.. anytime I broke something the overlay would fire and show me what i broke,

arbassett · 2022-01-04T20:08:58Z

packages/vite/src/client/error.ts

+const RE_CHROME_STACKTRACE =
+  /^ {4}at (?:(.+?)\s+)?\(?(.+?)(?::(\d+))?(?::(\d+))?\)?$/
+const RE_FIREFOX_STACKTRACE =
+  /^(?:(?:(^|.+?)@))\(?(.+?)(?::(\d+))?(?::(\d+))?\)?$/


These feel a bit messy to me but they work. if someone wants to take a crack at making this cleaner i would appreciate it

arbassett · 2022-01-04T20:12:36Z

packages/vite/src/client/overlay.ts

+      if (!fileRE.test(text)) {
+        el.textContent = text
+        return
+      } else {
+        fileRE.lastIndex = 0
+      }


This was added to support none link stack frames like a non-error was thrown please check your browser's devtools for more information

this kinda feels hacky. would love any suggestions on how this should be handled

arbassett · 2022-01-04T20:39:09Z

packages/vite/src/client/error.ts

+    }
+  }
+
+  // TODO: add support for url source maps


Does vite even emit url sourcemaps in dev?

gluck · 2022-01-07T09:23:05Z

packages/vite/rollup.config.js

@@ -40,14 +40,16 @@ const clientConfig = {
  input: path.resolve(__dirname, 'src/client/client.ts'),
  external: ['./env', '@vite/env'],
  plugins: [
+    nodeResolve(),


Opening the door for dependencies (bundling) in client.mjs feels a bit risky.
Simply bundling source-map makes client.mjs grow from 17k to 127k.

gluck · 2022-01-07T09:23:52Z

packages/vite/src/client/error.ts

@@ -0,0 +1,266 @@
+import type { RawSourceMap } from 'source-map'
+import { SourceMapConsumer } from 'source-map'


Using source-map in browser seems a bit risky, 0.6 works fine but 0.7 introduced a wasm dependency, and 0.8 (beta) introduces a 300k whatwg-url one.

this method could probably be used when we have moved over to source-map-js

gluck · 2022-01-07T09:53:50Z

packages/vite/src/client/error.ts

+  sourceMapConsumer?: SourceMapConsumer
+  baseSource: string
+}> => {
+  const source = await (await fetch(fileName)).text()


Pretty clever way to get the source map for the file

Though if we consider that we're going to fetch something from vite server anyway, what about sending the error to the server for normalization instead (e.g. through the WS link: socket.send({ type: 'runtime-error', error})) ?
That'd avoid duplicating the work (normalizing errors in vite server & doing it also in vite client) and would also limit the use of dependencies in the client.

My 2c

Yea i agree, it would make more sense to use the websocket connection and move the processing over to the server.

patak-dev · 2022-04-04T16:12:14Z

Hey @arbassett, sorry for don't get back to you on this one. Now that 2.9 is out, we are starting to prepare for Vite 3.0, and this could be an interesting feature to have in the next Vite major in case you or someone else is interested in keep working on this.

When we talked with the team about this PR, we discussed that:

We should move the logic to the server so we keep the client code size small, as proposed by @gluck here: feat: runtime error overlay #6274 (comment). We now have a new API in case it is useful https://vitejs.dev/guide/api-plugin.html#client-server-communication, but I think this may be done as an implementation detail.
There were some worries that people will confuse a runtime error with a Vite error. To avoid this, we should tweak the UI enough to avoid this. I think a different color theme may be enough.
Add an option that is disabled by default.

Another idea, since we have a good client server API maybe we should first check if an external plugin is possible (maybe with some smaller changes or APIs in core). Having it in core could still be the way to go.

Collapsing React's error stack
potentially the same for vue. i've never worked with vue before so I'm unfamiliar to how errors are handled
Should we provide a api for plugins to extend this so we don't have to handle errors for every possible framework ie import.meta.error

This is interesting, maybe we could check how other build tools handle this?

How should multiple errors be handled

Should we show multiple overlays at the same time an require multiple clicks from the user

Should be collect multiple errors and provide a button to toggle between them

I think we should go with the second option, requiring multiple clicks could be quite bad for some projects.

Should the user be able to follow the stack trace down with sources
Should users be able to view the error in source and compiled

I think we could start without these.

arbassett · 2022-04-05T00:31:30Z

@patak-dev thanks for getting back to me on the questions.

I'm hoping I will have some more time to work on this feature when work dies down.. but if anyone feels like they want to pick it up before I get a chance feel free.

We should move the logic to the server so we keep the client code size small, as proposed by @gluck here: #6274 (comment). We now have a new API in case it is useful https://vitejs.dev/guide/api-plugin.html#client-server-communication, but I think this may be done as an implementation detail.

when I saw the work starting on this I figured its better to wait until its done as its basically what was suggested.

Another idea, since we have a good client server API maybe we should first check if an external plugin is possible (maybe with some smaller changes or APIs in core). Having it in core could still be the way to go.

I think this is the right way to go. at the very least it should allow faster prototyping

There were some worries that people will confuse a runtime error with a Vite error. To avoid this, we should tweak the UI enough to avoid this. I think a different color theme may be enough.

do we have a preference on what colour. I'm not super keen on yellow (warning) or green (everything is good). maybe something thats not used to often like purple/violet

patak-dev · 2022-04-05T05:04:47Z

Another idea, since we have a good client server API maybe we should first check if an external plugin is possible (maybe with some smaller changes or APIs in core). Having it in core could still be the way to go.

I think this is the right way to go. at the very least it should allow faster prototyping

Nice, yes, modifying core is a lot more involved. If this could be an external plugin for some time, we may be able to move quicker, get users and feedback, and then at one point we could add it built in if that makes sense.

There were some worries that people will confuse a runtime error with a Vite error. To avoid this, we should tweak the UI enough to avoid this. I think a different color theme may be enough.

do we have a preference on what colour. I'm not super keen on yellow (warning) or green (everything is good). maybe something thats not used to often like purple/violet

Yes, I was also thinking about that tones. We could also add a label to make it more clear. IMO, we also don't need to be constrained by the current overlay design here. Maybe for runtime errors, it makes more sense to have something less intrusive? For a Vite error, we normally want to cover the screen, but for runtime errors, maybe the UI is functional? And we could use temporal toasts that don't block the UI?

Just an idea, but we could play with a DX that is more fit to each error type.

bluwy · 2022-06-16T07:15:59Z

+1 for toasts too, otherwise we may get similar request like vercel/next.js#13387

hichemfantar · 2023-01-13T22:20:14Z

This is very good work! Any idea when this gets merged?

Inviz · 2023-01-18T06:34:51Z

Is there a way to use it without maintaining forked vite?

mmartian · 2024-12-04T13:47:18Z

+1 to having this be implemented plz. Just recently migrated from webpack to vite and was stunned to see the error overlay was not as developed or easily customizable.

Shinigami92 added the p2-nice-to-have Not breaking anything but nice to have (priority) label Dec 28, 2021

arbassett added 11 commits December 29, 2021 12:19

feat: poc

79ac672

fix: better sourcemap parsing

f90fdf5

chore: add more testing samples

3a51bc1

chore: dead code removal

cd55215

feat: transform stack traces

fb6ce0d

feat: basic unhandledrejection handler

50047e7

chore: formatting

b975f80

fix: better regex parsing

a387e1c

fix: consistant lineNo whitespace

678e11f

feat: support unhandledRejection stack frames

a31eec7

fix: bundle source-map for client

2cf71fc

arbassett force-pushed the runtime-error-overlay branch from 561411c to 2cf71fc Compare December 29, 2021 18:43

arbassett added 7 commits December 29, 2021 14:22

fix: remove development console.log

4a1c910

fix(overlay): support non-url stack traces

c2b086e

feat: refactor & support non-error errors

b8e11b3

chore: formatting

8fde859

chore: more test cases

9dee968

fix: handle rejection with no stack

4017f98

chore: add tests

d7afc02

chore: add build test

4d7c0d8

patak-dev mentioned this pull request Dec 30, 2021

feat: read error from custom element attributes in vite-error-overlay #5686

Closed

9 tasks

arbassett added 6 commits January 4, 2022 14:22

fix: extract getStackLineInformation to error.ts

14f4428

chore: getStackLineInformation tests

dbf0100

fix: better happy path

ab42107

fix: extract error code to error.ts

1de3430

fix: respect __HMR_ENABLE_OVERLAY__

be450fa

chore: formatting

25c80f9

chore: comment cleanup

3eefedb

arbassett commented Jan 4, 2022

View reviewed changes

chore: code cleanup

61e9121

arbassett marked this pull request as ready for review January 4, 2022 20:27

arbassett commented Jan 4, 2022

View reviewed changes

gluck reviewed Jan 7, 2022

View reviewed changes

TechAkayy mentioned this pull request Jan 25, 2022

[Feature request] Show browser error overlay for runtime errors #2076

Open

sapphi-red added the needs rebase label Jun 14, 2022

mattrunyon mentioned this pull request Sep 8, 2022

Add dev error overlay to Vite deephaven/web-client-ui#748

Open

patak-dev mentioned this pull request May 16, 2023

Do not show full screen error dialog for syntax errors and HMR #13220

Closed

4 tasks

hi-ogawa mentioned this pull request Oct 28, 2023

feat: create vite runtime error overlay plugin hi-ogawa/unocss-preset-antd#100

Merged

2 tasks

patak-dev removed the needs rebase label Feb 12, 2024

hi-ogawa mentioned this pull request Apr 10, 2024

fix: fix accumulated stacks in error overlay #16393

Merged

This comment has been minimized.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: runtime error overlay #6274

feat: runtime error overlay #6274

arbassett commented Dec 27, 2021 •

edited

Loading

arbassett commented Dec 27, 2021 •

edited

Loading

arbassett commented Dec 30, 2021 •

edited

Loading

arbassett Jan 4, 2022

arbassett Jan 4, 2022

arbassett Jan 4, 2022 •

edited

Loading

gluck Jan 7, 2022

gluck Jan 7, 2022

Niputi Jan 7, 2022

gluck Jan 7, 2022

arbassett Jan 9, 2022

patak-dev commented Apr 4, 2022

arbassett commented Apr 5, 2022

patak-dev commented Apr 5, 2022

bluwy commented Jun 16, 2022

hichemfantar commented Jan 13, 2023

Inviz commented Jan 18, 2023

This comment has been minimized.

mmartian commented Dec 4, 2024

		@@ -0,0 +1,266 @@
		import type { RawSourceMap } from 'source-map'
		import { SourceMapConsumer } from 'source-map'

feat: runtime error overlay #6274

Are you sure you want to change the base?

feat: runtime error overlay #6274

Conversation

arbassett commented Dec 27, 2021 • edited Loading

Description

Additional context

What is the purpose of this pull request?

Before submitting the PR, please make sure you do the following

arbassett commented Dec 27, 2021 • edited Loading

arbassett commented Dec 30, 2021 • edited Loading

arbassett Jan 4, 2022

Choose a reason for hiding this comment

arbassett Jan 4, 2022

Choose a reason for hiding this comment

arbassett Jan 4, 2022 • edited Loading

Choose a reason for hiding this comment

gluck Jan 7, 2022

Choose a reason for hiding this comment

gluck Jan 7, 2022

Choose a reason for hiding this comment

Niputi Jan 7, 2022

Choose a reason for hiding this comment

gluck Jan 7, 2022

Choose a reason for hiding this comment

arbassett Jan 9, 2022

Choose a reason for hiding this comment

patak-dev commented Apr 4, 2022

arbassett commented Apr 5, 2022

patak-dev commented Apr 5, 2022

bluwy commented Jun 16, 2022

hichemfantar commented Jan 13, 2023

Inviz commented Jan 18, 2023

This comment has been minimized.

mmartian commented Dec 4, 2024

arbassett commented Dec 27, 2021 •

edited

Loading

arbassett commented Dec 27, 2021 •

edited

Loading

arbassett commented Dec 30, 2021 •

edited

Loading

arbassett Jan 4, 2022 •

edited

Loading