Skip to content

Three electron-vite dev-mode behaviors that silently corrupt a debugging session

TL;DR.

electron-vite dev auto-relaunches Electron on main/preload edits (spawning parallel instances), never hot-reloads guest preloads (causing silent version skew inside webviews), and does not forward extra CLI launch args like --user-data-dir — three no-error failure modes that waste real debugging time.

BLUF: under electron-vite dev, only the renderer is truly live. Everything else — main, preload, guest preloads, launch args — behaves in ways that produce no error and quietly invalidate what you think you're testing. Three behaviors bit us across several debugging sessions on an Electron desktop app (Electron 43.x, electron-vite current as of mid-2026).

1. Editing main/preload source relaunches Electron beside the instance you're watching

electron-vite's dev mode watches the main and preload build targets and relaunches Electron on every save. Edit a main-process file while an instance is up and you now have two app instances — and the old one's children can orphan, so pattern-based pkill reports success while ps still shows live Electron processes. We repeatedly "killed everything," then saw two windows. Compounding it: requestSingleInstanceLock makes a duplicate manual launch exit silently with no output, which looks like a failed launch rather than a lock.

Discipline that works: don't edit main/preload source while a dev instance runs; kill by explicit PID and verify zero Electron processes system-wide before each relaunch; isolate any deliberately-parallel instance with its own user-data directory.

2. Guest preloads injected into webviews never hot-reload — version skew is silent

Only the renderer target hot-reloads. A preload the main process injects into <webview> guests is a separate build target that keeps running stale. We changed the plumbing so the renderer stopped sending a color value; the old guest preload still interpolated it into border: 1px dashed ${accentHex}, producing 1px dashed undefined — and Chromium silently drops an invalid declaration. Result: a feature disappeared entirely, while the dev log showed HMR (client) rebuilds applying, so the code looked live.

Rule: any change touching main or preload source requires a full app restart. The failure mode is never an error — it's an old half of a contract talking to a new half.

3. Extra launch args are not forwarded — --user-data-dir no-ops

Passing --user-data-dir (e.g. to isolate a test/agent-driven instance from the real profile) through the dev command does nothing: electron-vite does not forward extra launch args to the Electron binary. The app starts fine and writes to the real Chromium profile. No warning. If you need isolation under dev, build an app-level seam instead — an env-var-driven app.setPath('userData', ...) at boot.

Takeaway

All three share a shape: dev-mode convenience hides a process boundary (relaunch, stale target, swallowed argv) and the failure is silence, not an error. When an Electron dev session behaves impossibly — two windows, code that "can't" be running, state in the wrong profile — audit the dev harness before the app.

No signals yet