feat(plugin-vite): render Vite build and dev-server output in the terminal multi-logger

[claude]

Requested by Erick Zhao · Slack thread

Stacked on #4389 (merged).

Before: With the Vite plugin, forge start prints the two Vite watch subprocesses' stdout/stderr straight to the console, interleaved with the Electron app's output and with each other; the renderer dev servers' request/HMR/error logs go to the console through Vite's default logger; nothing tells you at a glance which target is rebuilding, succeeded or failed.

After: Each build target (Main (src/main.ts), Preload (src/preload.ts)) and each renderer dev server (Renderer (main_window)) gets its own tab in the terminal UI next to core's App tab, with a live status (spinner while building, ✔ 11ms on success, ✖ 1 on error) that updates on every rebuild; Vite's HMR and error output lands in the renderer's tab and marks it warning/error until the next HMR cycle. In a non-TTY or CI the same output is written as [Main (src/main.ts)] … lines, and a failing first build still shows the Vite error text.

This wires the Vite plugin into the shared multi-logger the same way the webpack plugin is, so the Vite output shows up as tabs with statuses instead of raw console writes.

How

• The plugin calls ensureSharedLogger() and only creates tabs on it; core owns the logger (start/stop, the App tab, r).
• Watch subprocesses: logger.attachProcess(child, tab.name) replaces the direct process.stdout/stderr forwarding. The stderr copy used to explain a worker that dies before its first build is kept as a second data listener.
• Richer IPC: subprocess-worker.ts now sends build-start, build-done { durationMs } and build-error { message } from the Rollup watcher's START/BUNDLE_END/ERROR events (typed in a new worker-messages.ts), alongside the existing first-build-done/first-build-error/reload-renderers. statusFromWorkerMessage maps them onto the tab status; first-build-done only fills in success when BUNDLE_END has not already reported the duration.
• Renderer dev servers: createTabLogger(tab, logLevel) is passed as Vite's customLogger (a user-provided customLogger still wins). It formats timestamped lines like Vite (<time> [vite] (client) …), honors logLevel, dedupes warnOnce, counts warnings/errors in the status and returns to success when Vite starts a fresh cycle (info with clear: true, i.e. an HMR update or page reload). The server URLs are logged into the tab once it is listening.
• Tab names are numbered (#2) when two targets share an entry. Docs: a "Compiler output" section in docs/config/plugins/vite.mdx.
• Tests: tab naming, status mapping, the custom logger, the worker's watch-mode IPC (first build with duration, failing build, real worker), and that the plugin's postStart leaves the app's stdio to core.

Open questions

• Tab order follows the plugin's task order (renderers first, since main needs their ports): Renderer, Main, Preload. Webpack lists Main Process first; happy to pre-create the build tabs so main comes first if that consistency matters.
• The "back to success on clear: true" heuristic for renderer tabs is a judgement call: it is what Vite uses to mark a new HMR/reload cycle, and a still-broken transform re-marks the tab error right after, but there is no explicit "resolved" signal from Vite.
• Pre-existing, left alone: the worker's closeBundle hook sends reload-renderers even when the build errored (unlike pluginHotRestart, which guards on the error argument). Worth a follow-up.
• The worker keeps logLevel: 'silent' and prints its own one-liners, so the tab shows target built src/main.js per rebuild rather than Vite's full asset table. Switching to Vite's own build output in the tab would be a small follow-up if preferred.

Smoke-tested through the real CLI on a template-derived fixture with a stubbed electron, both under a PTY (ink UI, tab switching, quit summary) and piped/CI (plain lines), including a broken main entry.

🤖 Generated with Claude Code

https://claude.ai/code/session_017gBeqc5gc2rBabA5Xs4BmJ

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Working with Samuel Attard and Erick Zhao

zizmor Static Analysis is red here, but not because of this PR: it touches nothing under .github/. The org-required Zizmor Audit started gating main today when next was promoted, and main's ci.yml/gh-pages.yml never got the cache-poisoning hardening 7.x has from #4200, so every PR into main fails the same 4 findings. Fix is #4401; I've cherry-picked it here so this PR can go green (it no-ops once main has it).

---

Generated by Claude Code

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline finding, this run also examined and ruled out two other candidates: the new per-rebuild process.send() calls in subprocess-worker.ts's Rollup watcher event handler use the same unguarded process.send?.() pattern the pre-existing first-build-done/first-build-error messages already relied on, so the higher call frequency isn't a new failure mode; and a renderer dev-server startup failure (VitePlugin.ts:529) still propagates as a rejected Listr task rather than being silently swallowed, even though the tab visually stays at "building".

Extended reasoning...

This run reported one confirmed pre-existing bug (stderr cleared before being read into the error message in spawnViteBuildWatch's settle()) as an inline comment, so approval is off the table per the guidelines. Two prior rounds' inline threads (VitePlugin.ts:533 forcing tab status to success, logging.ts:123 status updates ignoring the log threshold) were resolved only by this bot's own session, which the instructions say is not independent sign-off, so I did not restate or treat them as settled. I additionally verified, by reading the diff directly, that the confirmed settle()/stderr bug is byte-for-byte identical to the base branch's version (just wrapped in the new logger/tab plumbing), confirming it's pre-existing rather than newly introduced. I also spot-checked the two other candidates the pipeline flagged and ruled out (unguarded process.send() on every rebuild, and a renderer tab getting stuck at "building" on a startup failure) against the code and found the ruling-out reasoning plausible: the send pattern is unchanged from what already existed for the first-build messages, and a startup failure's exception still propagates through the Listr task rather than being swallowed. Since new, non-redundant information exists (the ruled-out items) beyond what I posted in the prior two reviews, a brief informational note is warranted rather than staying fully silent, but decision cannot be "approve" while a verified finding is being posted inline.

[claude]

Code review found no issues

No high-confidence issues detected in this change.