feat: forward browser console logs and errors to dev server terminal

[hi-ogawa]

Description

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

This PR adds a browser-to-server console forwarding feature for dev server, so runtime client signals can be surfaced directly in terminal output. This is useful for development with coding agent as the server side log can be easier to be read. For example, when running playwright e2e with Vite dev server in webServer config, playwright pipes stderr by default and it allows agent invoking playwright cli to see through browser side runtime errors and logs directly.

Configuration

The basic shape of configuration is a following:

{
  server: {
    // `true` means { unhandledErrors: true, logLevels: ["error", "warn"] }
    forwardConsole: boolean | {
      unhandledErrors: boolean,
      logLevels: string[] // such as "error", "warn", ...
    }
  }
}

The default becomes true when @vercel/detect-agent detect it's running under coding agent. Otherwise it's false.

Implementation

The implementation of forwarding and formatting are heavily based on Vitest since the need is basically same. The error stack formatting uses parseErrorStacktrace utility provided by @vitest/utils. For console formatting though, as it depends on external dependency loupe or @vitest/pretty-format, I didn't use the one from @vitest/utils
and instead, copied the similar logic directly to Vite but without sophisticated object formatting.

Comparison with other tools

There are plugins providing similar features, but they didn't seem to have proper stack trace mapping nor console argument formatting.

• 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)

Many bundles have similar features as builtin. Most off them enable it by default, but Next.js seems to have this as op-in still (it could be just due to their test infra harder to adopt). You can find examples in:

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

Follow-up discussion if needed

• Currently client envrionment only. This can be extended to other environments but known cases have shared terminal with server, so explicit forwarding logic is likely not necessary. Can be revisited if there's a need.
• Opt-in or opt-out?
  • In my opinion, this should be enabled by default eventually since I'd expect it can benefit general users. If that happens, we also don't need agent detection. But this might disturb ecosystem, so maybe flip in future major.

Example

[pkg-pr-new]

Open in StackBlitz

@vitejs/plugin-legacy

pnpm add https://pkg.pr.new/@vitejs/plugin-legacy@20916 -D

npm i https://pkg.pr.new/@vitejs/plugin-legacy@20916 -D

yarn add https://pkg.pr.new/@vitejs/plugin-legacy@20916.tgz -D

vite

pnpm add https://pkg.pr.new/vite@20916 -D

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

yarn add https://pkg.pr.new/vite@20916.tgz -D

commit: 07dcd84

[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

[hi-ogawa]

I experimented with enabling forwardConsole: true by default. Vite's own CI should pass and the result of ecosystem ci above #20916 (comment) is also with that mode. Now the experiment is reverted back.

[hi-ogawa]

This was the only one failing when enabling forwardConsole by default on Vite. I adjusted it to make it more robust.

[sapphi-red]

Looks good to me 👍

[bluwy]

Personally I'm conflicted if we should detect agents and enable by default, but not enough that I'd block the PR, just unfortunate that it has a huge license file.

Otherwise I think this is a nice feature to have and indeed we can consider enabling by default in the future.

[graphite-app]

TOCTOU (Time-of-Check-Time-of-Use) race condition: The file existence is checked in the find() predicate (line 116), but the file is read later without error handling. The file could be deleted between the check and read, causing an unhandled exception.

if (stack === nearest) {
  try {
    const code = fs.readFileSync(stack.file, 'utf-8')
    output += generateCodeFrame(code, stack).replace(/^/gm, '    ')
    output += '\n'
  } catch {
    // Skip code frame if file is no longer accessible
  }
}

This will crash the error formatting when files are modified/deleted during development.

Suggested change

	if (stack === nearest) {
	const code = fs.readFileSync(stack.file, 'utf-8')
	output += generateCodeFrame(code, stack).replace(/^/gm, ' ')
	output += '\n'
	}
	if (stack === nearest) {
	try {
	const code = fs.readFileSync(stack.file, 'utf-8')
	output += generateCodeFrame(code, stack).replace(/^/gm, ' ')
	output += '\n'
	} catch {
	// Skip code frame if file is no longer accessible
	}
	}

Spotted by Graphite



Is this helpful? React 👍 or 👎 to let us know.