fix(runner): inject the Tier-1 reporter on one line (DEV-2557)

[demtario]

What was broken

injectReporter prepended the whole reporter body to the JS module entry — runner/packages/runtime/src/monitor.ts:684, REPORTER_SOURCE + "\n" + source. Everything the bundler reports for that file is offset by whatever we put above it, and the visitor is shown those positions verbatim, so a syntax error typed on line 31 of a 70-line file came back as (257:22). The prefix is 283 lines today and was 226 at the two Sentry release SHAs the events are tagged with (measured with git show <sha>:runner/packages/runtime/src/monitor.ts at 1fc5b1fb and cecbc7bc, not inherited — the ticket's premise number of 186 is wrong, and 226/283 is what the code actually was).

The module branch now prepends REPORTER_MODULE_LINE, a single physical line: try{(0,eval)(${JSON.stringify(REPORTER_SOURCE)})}catch(e){}. One line of prefix, one line of shift. REPORTER_SOURCE itself is byte-unchanged, injectReporterIntoHtml and the HTML branch are untouched, and sandpack.ts's file plumbing is untouched. The indirect (0,eval) form is what makes the reporter's bare window/parent/document/location resolve, since indirect eval evaluates in global scope; the try/catch is there so that if eval is ever unavailable it costs monitoring on this path and never the demo.

The regression this PR also fixes, found on review of its own first commit

Collapsing the reporter to one line fixed the reported line number and broke the code frame. Babel prints the two lines above the fault verbatim, so a syntax error on authored line 1 or 2 of the entry renders all 12.6 KB of REPORTER_MODULE_LINE into the compile message ahead of the offending line, and MONITOR_COMPILE_MESSAGE_MAX (2,000) then cuts. Measured on the vue starter's entry with an unterminated string on line 1, driving the real @babel/standalone transform over the real injectReporter output: 289 characters of usable message with the caret intact when the reporter was still inlined, 12,872 characters with it on one line and the visitor's own source line first appearing around character 12,400 — i.e. gone. That is DEV-2550's buried-diagnostic failure (DEMOS-15) returning on the same channel, the error card and Sentry.captureException, sourced from our own bytes instead of an inline source map. boundCompileMessage in runner/packages/runtime/src/sandpack.ts:266 now replaces that line with a short marker, next to the existing source-map strip and before the cap, so the diagnostic and the caret survive.

The strip matches the exported constant with split/join rather than a pattern, deliberately: a regex over the injected shape would keep passing its own tests while silently ceasing to match a reworded injection, and the burying would come back with nothing red. The constant is the coupling.

Sentry and ClickUp

DEMOS-15 (contributing cause) — the sandpack-compile class, which is the only visitor-facing class this touches. DEMOS-17 and DEMOS-18 are runtime stack frames rather than compile diagnostics, so they are unaffected either way; the ticket lists them, and that part of its premise does not hold. Task: https://app.clickup.com/t/86cb68qpm (DEV-2557).

What was verified, with the actual commands

pnpm build then pnpm test then pnpm typecheck, run raw at runner/ (never through an rtk filter): 575 tests, 575 pass, 0 fail, 0 skipped, and all four typecheck projects clean. Seven tests are new. The module entry is shifted by exactly one line, checked line-by-line against the authored split rather than against a constant. The injected prefix carries no LF, CR, U+2028 or U+2029 — built with String.fromCharCode so a formatter cannot normalise away the characters the test exists to reject, and pointed at the two JSON.stringify does not escape. The eval form is executed, not assumed: the injected entry runs in a node:vm context whose globals are the same stubs the existing suite uses, and its payload is compared against the inlined run's, which required extracting makeReporterStubs() because runReporter's new Function(param…) trick structurally cannot reach an indirect eval. Module-entry idempotency and byte-determinism are pinned (the existing pair covered the HTML entry only). The code-frame test drives real babel over real injectReporter output and asserts its own premise first — untreated, the message is over the cap and the visitor's line is past it — so it cannot pass by the blob never having been there; verified by mutation, dropping the strip fails it and nothing else.

The eval itself could not be checked by e2e: monitorDemos is reportingEnabled && VITE_MONITOR_DEMOS === "1", and reportingEnabled is pinned to the production host and gated on navigator.webdriver (DEV-2540), so under Playwright the injection never runs at all. It was checked by hand instead, with the gate temporarily forced open in apps/authoring/src/sentry.ts: window.__hotRunnerMonitor is true inside the real Sandpack preview iframe for both a vue and a react entry. That patch was reverted and is not in this diff.

Deliberately out of scope

This does not make line numbers correct, and the PR should not be read as claiming it does. The entry is generally transpiled before the injection — transpileFilesForParcel for the parcel entries, and babel does not use retainLines — so a reported line is still a compiled line. Measured on the vue starter, a syntax error typed on authored line 11 now reports line 14: the residual +3 is that entry's own TS transform. What changed is that we stopped adding 283 lines of our own on top of it. Source maps are the actual path to correct line numbers, and with the injection down to one line the transpile map is the only remaining unknown; that is a separate ticket, and this change is a prerequisite for it rather than a competitor.

The HTML entry keeps its ~283-line shift. That path is Tier-2's only monitoring channel (runner/workers/api/src/monitor-inject.ts), and widening the eval bet to it wants its own decision, so a visitor with an inline <script> syntax error in index.html still gets a wrong line.

The eval is the sole monitoring channel for more starters than the plan assumed. runner/config/frameworks.json puts create-react-app, create-react-app-typescript and vue-cli outside HTML_ENTRY_ENVS, so resolveSandboxEntry returns the JS module for all of them and there is no <script> fallback — roughly eight starters, not the single vue entry the plan described. If a preview ever carries a script-src without 'unsafe-eval', the catch swallows it and monitoring goes off silently on all of them. Parcel and static entries keep the HTML channel and are unaffected.

The regression fixture runs @babel/standalone 8, while the message that actually reaches boundCompileMessage comes from the hosted bundler's babel — 6.26 for parcel entries, whatever the vue-cli and CRA templates run for the rest — and neither is pinned by us. No babel code-frame implementation truncates context lines, and if one ever did the strip would stop matching and the behaviour would degrade to the pre-fix message rather than to anything worse, so this is a known gap between the test and production rather than a blocker.

One comment was corrected rather than left standing: the acorn ES5 guard claimed the symptom of a slip in REPORTER_SOURCE is a blank Tier-1 preview, which stopped being true for the module path the moment the reporter went inside a try/catch — a parse failure there is now swallowed and costs monitoring silently. The guard must also stay pointed at REPORTER_SOURCE and never at the injected output, which is a single string literal that parses at ES5 forever; there is a comment saying so, because repointing it would be a permanent false green.

🤖 Generated with Claude Code