improve sketch error messages in the editor console

[Nixxx19]

closes #4088.

opened the issue first because the editor console was surfacing much less info than the browser devtools, and i wanted to check the direction with maintainers before coding. this pr pulls together what was discussed there.

the short version of the problem: jshint was catching parse errors during preprocessing and then throwing them away, so syntax errors either silently disappeared or got replaced by a generic browser message with no file or line. runtime errors went through two different code paths with different output. the console message was a plain string, so the editor decoration had to re parse the string to recover the file and line it needed, and for blob urls it often failed and fell back to showing the raw blob path.

what the pr does:

1. keep the jshint errors instead of dropping them. surface them with the correct file, line and column, and a short hint that is tailored to the specific jshint reason (expected identifier, missing semicolon, unclosed string, unmatched brace, missing = in a let/const/var, etc). one friendly block covers all errors on a run with a single mdn reference at the end, not one block per error.
2. configure jshint for modern js (esversion 11, asi, laxbreak, laxcomma) so let, const, arrow functions etc no longer produce false positives.
3. unify window.onerror with StackTrace.fromError, which unhandledrejection was already using. runtime errors now carry a full stack trace instead of one line.
4. resolve blob filenames back to the user's source filenames using the existing window.objectUrls and window.objectPaths maps, with a fallback for when the browser strips the blob prefix.
5. send a structured meta object alongside the string so the editor decoration can just read the line numbers instead of reparsing stack strings. when a sketch has multiple errors, every affected line in the selected file gets the red gutter, not just the first.
6. compute the line offset of each inline script in index.html up front, so jshint errors inside inline scripts report the correct html line and the decoration lands on the actual broken line.
7. when there are fatal parse errors in a file, replace the content with a short placeholder before the iframe runs it. stops the browser firing its own noisier parse error on top of the jshint message we already emitted.

test plan, run locally against a clean p5 sketch:

• default sketch, no errors, canvas runs normally
• single syntax error in sketch.js, error shows with file and line, red gutter on the line
• multiple syntax errors in sketch.js, all shown together, all lines decorated
• syntax error inside an inline <script> in index.html, editor auto switches to index.html and decorates the correct line
• runtime ReferenceError in draw, full stack with resolved filenames
• sketch using let, const, arrow functions, template literals, no false positives

note: the red overlay that shows in the preview iframe during dev is webpack dev server's runtime error panel from react-refresh-webpack-plugin, not something this pr controls. it does not exist in production builds.

[Nixxx19]

left one is before and right one is after :

---

---

[aadityasingh9601]

Hi @Nixxx19, I have pulled your branch locally & tried to produce some errors by running some sketches.
The new error messages are more detailed & helpful, that's good!

But check out this particular case when I tried to add <script> broken </script> in the index.html file.

Error.msg.bug.mp4

As shown in the video, when error occurred, a new window opened up that shows the error.
The issue here is --

a. The window that opens up shows the same error in both slides. One of them can be removed.
b. The window that opens up covers the full screen, can we adjust it such that it only shows up in the "preview" part of the page. Just like shown in the video too after clicking on the "close" button once.

[Nixxx19]

hey @aadityasingh9601, thanks for testing this out!

so that full-screen red popup is actually webpack's dev-server overlay, not something the pr is rendering. it only runs in dev mode (npm start) and isn't part of the production bundle, so users on editor.p5js.org won't ever see it.

that said you helped me catch a real bug behind it. the html line offset wasn't being applied for inline scripts because of a small string mismatch (/index.html vs index.html), so the editor ended up trying to decorate a line past the end of the file and threw a rangeerror. that throw is what triggered the overlay locally.

just pushed a fix for it. also added a small range guard on the decoration call so it can't blow up on out-of-range lines. pull latest and it should be gone. the in-editor console message and gutter highlight still work normally.

[aadityasingh9601]

hey @aadityasingh9601, thanks for testing this out!

so that full-screen red popup is actually webpack's dev-server overlay, not something the pr is rendering. it only runs in dev mode (npm start) and isn't part of the production bundle, so users on editor.p5js.org won't ever see it.

that said you helped me catch a real bug behind it. the html line offset wasn't being applied for inline scripts because of a small string mismatch (/index.html vs index.html), so the editor ended up trying to decorate a line past the end of the file and threw a rangeerror. that throw is what triggered the overlay locally.

just pushed a fix for it. also added a small range guard on the decoration call so it can't blow up on out-of-range lines. pull latest and it should be gone. the in-editor console message and gutter highlight still work normally.

Hi @Nixxx19, thanks for the clarification about the red popup, now I get it.
Also, I am glad to help you out with this. I will pull the latest changes now & test the PR further by running some more sketches, will report here if anything else feels off.

[skyash-dev]

hi @Nixxx19!

any idea why i see different console errors instead of "Unexpected token"?

[Nixxx19]

hi @Nixxx19!

any idea why i see different console errors instead of "Unexpected token"?

hey @skyash-dev! firefox only uses Unexpected_token in its mdn url, the actual console message it emits is expected expression, got ';', no "token" in the text itself. chrome is the one that puts Unexpected token in the message. our editor console just forwards whatever the browser throws so wording will always vary across browsers

the RangeError tho is the html line offset bug, this pr fixes it. pull and rerun, should be gone

[skyash-dev]

i think the decoration clearing may be better scoped to the empty-error case:

if (consoleErrors.length === 0) {
  removeErrorDecorations(codemirrorView.current);
  return;
}

readable + more stable

[Nixxx19]

i thought about scoping it but kept the unconditional clear on purpose. if a user has an error on line 5, fixes it, then introduces a new error on line 10 on the next run, skipping the clear leaves the old gutter on line 5 even though its already fixed. clear-then-add guarantees the gutters always reflect just the latest run, happy to revisit if you can think of a case where the always-clear causes flicker or perf issues

[skyash-dev]

using only consoleErrors[0] actually seems reasonable to me from a UX perspective.
reflects an implicit assumption that:

• the first runtime error is usually the most actionable
• one clear navigation target is often better than many competing ones
• stability/readability matters more than exhaustiveness

maybe.

• keep console output/navigation focused on the primary error only
• but surface all resolved runtime errors through error decorations tooltips

that could reduce console noise while still making secondary issues discoverable contextually near the affected lines.

something similar is already done in editors/platforms like openprocessing, where the primary runtime issue is emphasized while additional diagnostics remain attached to the code locations themselves.

[Nixxx19]

• the decorate-all part is already in the pr, targetFileId = pairs[0].file.id for navigation/focus and every error in that file gets addErrorDecoration so all the lines get a red gutter
• where we differ is the console output, the pr surfaces all errors as text instead of hiding secondary ones behind hover tooltips. kept it that way because the editor audience is mostly beginners and hover-only info gets missed easily
• tooltip widgets on decorations would also be new infra, probably better as a follow up, happy to open an issue to track it if you think its worth doing