electron-vite: Vite-based build tooling for Electron apps, and what it does not do

The Electron build gap electron-vite fills

An Electron app is not one program. It is a Node process (main), a privileged bridge script (preload), and a browser page (renderer). Each has a different module system, a different set of globals, and a different target. A single Vite config cannot serve all three honestly, because the renderer must not be bundled with Node built-ins and the main process cannot be bundled as if it were browser code.

electron-vite's answer is a config file with three top-level keys. The README shows the shape: main, preload and renderer, each holding ordinary Vite config options. The tool resolves electron.vite.config.js from the project root when you run the binary. That is the whole conceptual surface. If you have written a vite.config.js, you already know how to configure this.

The intended audience is narrow and identifiable: developers building desktop apps with Electron who want Vite's dev server semantics rather than webpack's. The README lists TypeScript, Vue, React, Svelte and SolidJS support out of the box, which matches the template presets in the create-electron scaffolder. If your team has no Vite experience, the tool still works, but you lose the main reason to prefer it over a webpack-based setup.

How the three-target build and hot reloading actually work

The mechanism is a CLI plus a config resolver. The bin entry maps electron-vite to bin/electron-vite.js, and the package exports dist/index.js with types at dist/index.d.ts. Three subcommands matter in daily use: dev, build and preview.

In development, dev starts a Vite dev server for the renderer and builds the main and preload targets so Electron can load them. The README advertises fast HMR and hot reloading, and lists isolated build for multi-entry application development as a separate feature. That isolation is the point: changing a preload script should not force a full renderer rebuild, and changing a renderer component should not restart the main process.

preview is the third command. It runs the app against built output rather than the dev server, which is what you want when checking whether a production build behaves like development. The distinction between dev and preview is a common source of confusion for newcomers, and the README does not spell out the difference in its usage section; it only lists both as npm scripts.

The source protection feature compiles code to V8 bytecode. This is a build-time transform, not encryption, and it applies to the targets you configure for it. The repository topics include bytecode and source-code-protection, and @swc/core appears as an optional peer dependency, which is consistent with a transform that needs a compiler behind it. The README does not describe the threat model, so treat bytecode as a speed bump against casual inspection, not as a guarantee.

Installing electron-vite and running a first build

Install it as a dev dependency. The README gives the exact command:

npm i electron-vite -D

Then wire the binary into package.json scripts. These are the README's own script names and commands:

{
  "scripts": {
    "start": "electron-vite preview",
    "dev": "electron-vite dev",
    "prebuild": "electron-vite build"
  }
}

Create electron.vite.config.js in the project root. The README's minimal example is three empty objects, one per target:

// electron.vite.config.js
export default {
  main: {
    // vite config options
  },
  preload: {
    // vite config options
  },
  renderer: {
    // vite config options
  }
}

An empty config is valid because the tool ships pre-configured defaults optimized for Electron, per the feature list. Run npm run dev and you should get a dev server for the renderer plus built main and preload output. Run npm run prebuild to produce a production build, then npm start to preview it.

If you would rather start from a working project, the README offers two routes: clone electron-vite-boilerplate, or scaffold with create-electron:

npm create @quick-start/electron@latest

That scaffolder offers vanilla, vue, react, svelte and solid presets, each in a JavaScript and a TypeScript variant. Before any of this, check the engines field in package.json: it requires Node ^20.19.0 or >=22.12.0, and the Vite peer range is ^6.0.0, ^7.0.0 or ^8.0.0.

Where electron-vite stops: packaging, signing and auto-update

The README documents a build tool, not a distribution tool. There is no mention of code signing, installers, notarization, auto-update feeds, or platform-specific packaging. If you install electron-vite expecting an end-to-end pipeline from source to shipped .exe, you will be disappointed at the last mile.

The practical consequence is that electron-vite sits upstream of a packager in any real project. Its build output is input to something else. This is a deliberate separation, and it is defensible, but the README does not say so explicitly, which leaves the boundary to be discovered.

The second boundary is version churn. The peer dependency on Vite spans three majors, and the most recent releases are v6.0.0-beta.1 (2026-04-12) and v6.0.0-beta.0 (2026-04-09), with v5.0.0 as the last stable release (2025-12-07). The repository's last push was on 2026-08-18. Anyone pinning to a beta is accepting that plugin compatibility may shift between beta and stable. The README does not document a migration path between major versions, and CHANGELOG.md is the file to read instead.

A third limitation is tooling scope. The feature list mentions IDE debugging in VSCode or WebStorm, but the README does not explain how source maps are configured for each of the three targets. If debugging the main process matters to you, that is a question to answer from the documentation site rather than the README.

electron-vite against webpack-based Electron setups

The honest comparison is with webpack, which has been the default answer for Electron bundling for years. Electron Forge is the most visible example in the related searches, and it takes the opposite architectural position: it is a framework that owns scaffolding, packaging and publishing, with bundler support layered underneath.

That difference decides the choice. Forge gives you a project lifecycle. electron-vite gives you a build step and expects you to bring the rest. If your team already has a packaging pipeline and only wants faster rebuilds and a config format you know, electron-vite slots in with less ceremony. If you want one command that produces an installer, Forge covers ground electron-vite does not attempt.

Within the Vite ecosystem, the distinction is smaller. electron-vite is Vite plus Electron-specific defaults and a three-target config shape. The value over rolling your own Vite configs is the pre-configured defaults and the isolated multi-entry build, not a new plugin API. If you have already hand-written separate Vite configs for main and renderer and they work, migrating buys you consistency rather than capability.

The source protection angle has no direct counterpart in a plain webpack setup without adding a separate obfuscation or bytecode step. That is electron-vite's most distinctive feature, and also the one the README explains least.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-18, which is recent enough that the project is not dormant. That said, the version in package.json is 6.0.0-beta.1, so the current line is pre-release. Teams that require stable tags should look at v5.0.0 from 2025-12-07 and treat the v6 betas as something to evaluate separately.

Upgrade cost concentrates in the Vite peer range. Because electron-vite accepts ^6.0.0, ^7.0.0 or ^8.0.0, you can move Vite majors without moving electron-vite, but the reverse is not free: a new electron-vite major may change how the three targets resolve plugins. The README does not document a migration procedure, so the CHANGELOG.md at the repository root is the artifact to read before bumping. Budget time for it rather than assuming a drop-in swap.

The license is MIT, stated in the README and in package.json. MIT is permissive: it allows commercial and closed-source use, and it requires preserving the copyright notice and license text in distributions. That last point interacts with the bytecode feature in a way worth checking with your own counsel. Compiling your application code to V8 bytecode does not change the license obligations of the dependencies you bundle, and the README says nothing about how bytecode output is distributed. Nothing here is legal advice.

Editorial conclusion

Adopt electron-vite if your team already writes Vite config and wants one tool covering main, preload and renderer builds without learning a second plugin API. Do not adopt it if you need packaging, signing or auto-update, because the README documents none of those; that work belongs to a separate packager. Before committing, verify your Node version satisfies the engines field (^20.19.0 or >=22.12.0), confirm your Vite major is one of ^6.0.0, ^7.0.0 or ^8.0.0, and check whether the bytecode protection feature still requires the optional @swc/core peer dependency in the version you install.

Frequently asked questions

Official sources

1. alex8088/electron-vite on GitHub
2. License: MIT
3. Project website
4. README
5. Releases