improve sketch error messages in the editor console (wip)

[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.