Skip to content

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

Merged
sapphi-red merged 66 commits intovitejs:mainfrom
hi-ogawa:10-10-feat_log_unhandled_runtime_error_on_server
Mar 5, 2026
Merged

feat: forward browser console logs and errors to dev server terminal#20916
sapphi-red merged 66 commits intovitejs:mainfrom
hi-ogawa:10-10-feat_log_unhandled_runtime_error_on_server

Conversation

@hi-ogawa
Copy link
Contributor

@hi-ogawa hi-ogawa commented Oct 9, 2025

Description

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.

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:

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

image

@hi-ogawa hi-ogawa marked this pull request as ready for review October 9, 2025 16:50
@pkg-pr-new
Copy link

pkg-pr-new bot commented Oct 10, 2025

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
Copy link
Contributor Author

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
Copy link
Contributor

cpojer commented Oct 14, 2025

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
Copy link

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
Copy link
Contributor

cpojer commented Oct 15, 2025

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

@github-project-automation github-project-automation bot moved this to Discussing in Team Board Oct 15, 2025
@hi-ogawa hi-ogawa moved this from Discussing to P2 - 3 in Team Board Oct 15, 2025
@sapphi-red sapphi-red added the p3-significant High priority enhancement (priority) label Oct 15, 2025
@hi-ogawa
Copy link
Contributor Author

hi-ogawa commented Oct 15, 2025

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

@vite-ecosystem-ci
Copy link

📝 Ran ecosystem CI on 1b8e762: Open

suite result latest scheduled
qwik failure failure
astro failure ⏹️ cancelled
analogjs success failure
one failure failure
rakkas failure success
vike failure success
laravel failure success
react-router failure success
histoire failure success
nuxt failure success
vite-plugin-pwa failure success
storybook failure success

marko, ladle, unocss, sveltekit, vite-plugin-svelte, quasar, tanstack-start, vuepress, vite-plugin-react, vite-plugin-cloudflare, vitepress, vite-environment-examples, vite-setup-catalogue, vitest, vite-plugin-vue, waku, vite-plugin-rsc

@hi-ogawa
Copy link
Contributor Author

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.

Comment on lines +1065 to +1067
expect(
serverLogs.slice(lastServerLogIndex).map(stripVTControlCharacters),
).toContain('hmr update /self-accept-within-circular/c.js')
Copy link
Contributor Author

@hi-ogawa hi-ogawa Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@hi-ogawa hi-ogawa requested a review from sapphi-red February 25, 2026 01:25
sapphi-red
sapphi-red previously approved these changes Feb 27, 2026
Copy link
Member

@sapphi-red sapphi-red left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me 👍

@sapphi-red sapphi-red added this to the 8.0 milestone Feb 27, 2026
Copy link
Member

@bluwy bluwy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +133 to +137
if (stack === nearest) {
const code = fs.readFileSync(stack.file, 'utf-8')
output += generateCodeFrame(code, stack).replace(/^/gm, ' ')
output += '\n'
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Fix in Graphite


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

@hi-ogawa hi-ogawa requested review from bluwy and sapphi-red March 4, 2026 10:16
@sapphi-red sapphi-red merged commit 2540ed0 into vitejs:main Mar 5, 2026
24 of 25 checks passed
@hi-ogawa hi-ogawa deleted the 10-10-feat_log_unhandled_runtime_error_on_server branch March 5, 2026 08:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

p3-significant High priority enhancement (priority) trigger: preview

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

5 participants