feat: forward runtime error logs to server

[hi-ogawa]

Description

• Closes feat: collect errors from the browser #20487 (supersedes)

This PR adds server.forwardRuntimeLogs option, which enables forwarding unhandled runtime errors from browser to dev server and logs them on terminal.

I mostly ported Vitest's error reporting logic and it even bundles a part of @vitest/utils for stack trace parsing (the output below looks so familiar 😄). The code size is expected to be compact and proved to be robust, so I think this approach is fine.

I initially implemented in https://github.com/hi-ogawa/reproductions/tree/main/vite-20487-unhandled-error-to-console/runtime-log and userland plugin is possible (though with a caveat that ssr framework requires a way to inject script other than transformIndexHtml.)

TODO

• test
• docs
• actually test with agent
• discuss feature scope (maybe follow up)
  • naming things (currently it's vaguely named as server.forwardRuntimeLogs considering the future scope)
    • server.forwardConsole, environment[name].forwardConsole.
    • forwardConsole: boolean : { ... } boolean as simple true/false but additional option to refine specific console.xxx.
  • forward console.error? (e.g. react hydration error is not runtime but only console.error No, this wasn't the case.)
    • to be discussed but console.error should be picked up as top-level boolean = true case as well.
  • allow filter by error? some default we should filter out? (cf. vitest)
    • later but consider future extension
  • ssr runtime error? (global process.on like Vitest)
    • browser only first. but consider future extension.
  • expose this via mcp server? (cf. Feat: get_errors MCP endpoint vercel/next.js#84161)
    • think about this later
  • auto detect agent? (cf. https://github.com/search?q=%22process.env.CLAUDECODE%22&type=code)
    • can do.
    • propose standardized environment variable for AI CLI. send PR and feature request to attract opinion.
    • also research the default behaviors of other tools (next.js, rsbuild, bun)
  • should event type / payload considered public API? (should we adjust types to allow future extension without breaking change?)
    • for now internal.

Related plugins

• https://github.com/patak-dev/vite-plugin-terminal
• https://github.com/mitsuhiko/vite-console-forward-plugin
• https://github.com/unplugin/unplugin-turbo-console
• https://github.com/moshetanzer/nuxt-browser-to-server-logs
• https://github.com/antfu/nuxt-mcp (vite-plugin-mcp is in this repo)

Other bundlers

• https://github.com/hi-ogawa/reproductions/tree/main/vite-20916-demo-simple

Example

Example: Github Copilot fixing bug by checking server logs

https://github.com/hi-ogawa/reproductions/tree/main/vite-20916-demo

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vite@20916

commit: 3b1a07f

[hi-ogawa]

I realized this feature has never had a proper context. This has been raised internally in voidzero as a part of AI coding improvement and I've picked up after #20487. I'll create a proper feature request to accompany with this, but the code here is self-contained and ready for review.

[cpojer]

Some thoughts:

• How about forwardClientLogs since runtime is ambiguous (what runtime, the vite runtime, or the runtime that is using Vite-compiled bundles, or .. just the app code?)
• Ideally it should log all the console.* functions, but it's a lot of work. The minimum should be log, info, warn, error. Everything else is nice to have.
• Filtering is imho not needed in a first version (unless it is on by default). If it is on by default, an array of strings/regex for filtering would be good to be able to specify, because some people will complain.
• No opinion on the AI related questions.

[brendanmatkin]

Some thoughts:

• How about forwardClientLogs since runtime is ambiguous (what runtime, the vite runtime, or the runtime that is using Vite-compiled bundles, or .. just the app code?)
• Ideally it should log all the console.* functions, but it's a lot of work. The minimum should be log, info, warn, error. Everything else is nice to have.
• Filtering is imho not needed in a first version (unless it is on by default). If it is on by default, an array of strings/regex for filtering would be good to be able to specify, because some people will complain.
• No opinion on the AI related questions.

Yeah or even 'forwardBrowserLogs/Console'? Would it ever not come from a browser?

I think just 'error' to start would be good! Log/info could get pretty noisy - could include but default off if it's worth including?

[cpojer]

I recommend against using browser. Vite doesn't have to target a browser environment. forwardConsole might work.

[hi-ogawa]

Thanks for the feedback! We've discussed in the meeting and I updated the description to note some tweaks which I'll do later.

• How about forwardClientLogs since runtime is ambiguous (what runtime, the vite runtime, or the runtime that is using Vite-compiled bundles, or .. just the app code?)

My intent of "runtime" is that to contrast from Vite "plugin" side code (i.e. main Vite node process). Here "runtime" means each Vite environment including ssr and others and we could catch unhandled errors and patch console to do the same thing on ssr, which might run separately from main node process. However, the log and any errors there are usually already visible in the same console for known server environment. We'll adjust option structure and default behavior to take this into account. Also emphasizing the option as forwardRuntimeLogs doesn't seem to benefit anything, so I'm thinking to take forwardConsole as an option name.

• Ideally it should log all the console.* functions, but it's a lot of work. The minimum should be log, info, warn, error. Everything else is nice to have.

I think we can do this with the options to selectively pick some log levels, something like https://github.com/mitsuhiko/vite-console-forward-plugin?tab=readme-ov-file#usage