Library / SDK
electron-vite/electron-vite-vue avatar
electron-vite/electron-vite-vue

electron-vite-vue: a minimal Electron + Vite + Vue starter

🥳 Really simple Electron + Vite + Vue boilerplate.

4,895 stars635 forksTypeScriptMIT

At a glance

What is it?
electron-vite-vue packages Electron, Vite and Vue 3 into one small boilerplate with a three-entry directory layout. It suits developers who want Node APIs and a fast Vue dev server without adopting a full framework, and it stays thin on purpose.
Who is it for?
Adopt electron-vite-vue if you want a small Electron + Vue 3 + Vite base you can read end to end, and you are willing to wire routing, state and packaging choices yourself. Do not adopt it if you need a maintained release cadence, since the newest release is v28.0.0 from 2024-04-18, or if you want a framework that decides your project layout for you.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 30 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What electron-vite-vue is for, and who it fits

The README calls this a "Really simple Electron + Vue + Vite boilerplate", and the repository backs that up: the top level holds an electron/ directory, a src/ directory, index.html, vite.config.ts and electron-builder.json. That is the whole project. It exists so you do not have to assemble the wiring between an Electron main process, a preload script and a Vite-served Vue renderer before writing your first line of application code.

The audience is narrow and specific. You are building a desktop app with Vue 3 and TypeScript, you want Vite's dev server and hot reload rather than a webpack pipeline, and you want the option of calling Node.js APIs or loading a C/C++ native addon from the renderer. If any of those three is not true, the boilerplate is not buying you much. The README lists native addon support and Node.js API access in the renderer as headline features, which tells you the author expects that class of app rather than a plain website wrapped in a window.

It is a boilerplate, not a framework. There is no plugin system, no CLI that scaffolds routes or stores, and no opinion about how you organise components. The directory listing is deliberately short, and the README describes the structure as "Extensible, really simple". Whether that is a feature or a gap depends on how much you want decided for you.

How the three processes are wired together

The README's directory diagram is the clearest statement of the architecture. There are three entry points: electron/main/index.ts for the Electron main process, electron/preload/index.ts for the preload script, and src/main.ts for the renderer. The main process entry is what package.json points at for production, since "main" is set to "dist-electron/main/index.js".

Vite does the work of building all three. The repository depends on vite-plugin-electron and vite-plugin-electron-renderer, both listed as devDependencies, and the README explains that the renderer: {} preset in vite.config.ts is "only a Vite adapter that polyfills Electron, Node.js APIs and native modules for the renderer process". That sentence matters because it is easy to misread. Polyfilling Node APIs into the renderer during development is not the same as turning on Node integration in the BrowserWindow. The README is explicit that if you want direct Node.js access in the renderer you must enable nodeIntegration in the webPreferences of the main process, and it adds that you should review the security impact carefully. Treat those as two separate switches that happen to produce a similar developer experience.

The preload script sits between the two, which is where you would normally expose a narrow, typed API to the renderer instead of opening the whole Node surface. The boilerplate gives you the file and the build path for it, but the README does not prescribe an IPC pattern, so that boundary is yours to design.

Quick setup: clone, install, run

The README's Quick Setup section is four commands and no configuration. Clone the repository, enter the directory, install dependencies, and start the dev server. The package.json scripts confirm that dev maps to vite, so the Vite dev server is what launches the Electron window in development.

bash
git clone https://github.com/electron-vite/electron-vite-vue.git
cd electron-vite-vue
npm install
npm run dev

After npm run dev you should see an Electron window open with the Vue starter rendered inside it, and edits to files under src/ should reload without a restart. Note that the repository's package.json sets "type": "module", so configuration files are treated as ES modules.

For a production build the script chain is longer than the dev path, and each step can fail independently:

bash
npm run build

That runs vue-tsc --noEmit first, then vite build, then electron-builder. The type check runs before any bundling, so a TypeScript error stops the build before electron-builder is reached. Packaging configuration lives in electron-builder.json at the repository root, and that is the file to edit for app identity, targets and installer settings. The README does not document what electron-builder produces by default, so check the generated output for your platform rather than assuming.

Native addons and the renderer polyfill preset

Support for C/C++ native addons is listed as a feature, and the mechanism is the renderer preset from vite-plugin-electron-renderer. The README links its documentation for two specific topics: dependency pre-bundling for C/C++ addons and Node.js modules, and the distinction between dependencies and devDependencies. Those links are the actual guidance. The README itself does not explain how pre-bundling works, so a project that loads a native module will need to read that plugin documentation before the build behaves as expected.

The dependencies versus devDependencies question is not cosmetic here. Native modules and anything the main or preload process requires at runtime generally need to be installed as runtime dependencies so they survive packaging, while build tooling belongs in devDependencies. The current package.json puts every listed package, including electron, vite and vue, under devDependencies. That is consistent with a boilerplate where the renderer is bundled, but it is a pattern to revisit the moment you add a native addon, because the packaging step needs to know what to ship.

The security note is the other half of this story. A polyfilled Node API in the renderer during development is convenient, and the README is careful to say it is not the same as Node integration. If your app genuinely needs filesystem or process access from the renderer, the documented route is nodeIntegration in webPreferences, and the documented advice is to weigh the consequences. A preload script exposing a small set of functions is the narrower alternative, and the boilerplate already gives you the file for it.

Where electron-vite-vue gets in the way

The release history is the first thing to weigh. The most recent release listed is v28.0.0 from 2024-04-18, and before that v2.2.0 in 2023 and v2.0.0 in 2022. The repository has been pushed more recently, on 2026-09-01, but there is no tagged release in that window. If your team needs a versioned artifact with release notes to pin against, this project does not currently offer one, and you are tracking the main branch instead.

The second limitation is scope. The README does not mention routing, state management, auto-update, code signing, or testing. A Vue desktop app of any size will need at least routing and a store, and you will be choosing and wiring those yourself. The related searches around vue-router and devtools point at exactly this gap: people arrive expecting the boilerplate to have answered it, and it has not.

The third is the security boundary described above. The renderer preset makes Node APIs feel available, and the README's own wording warns that this is not the same as enabling Node integration. A team that skims that paragraph and then ships with nodeIntegration enabled for convenience has taken on a larger attack surface than they may have intended. The boilerplate does not enforce the safer pattern; it only documents it.

How it compares with Electron Forge and Tauri

Electron Forge is the closest comparison in kind. It is a scaffolding and packaging toolchain for Electron apps, and its centre of gravity is the build and distribution pipeline: makers for different targets, a plugin system, and a documented path from development to signed installers. electron-vite-vue inverts that emphasis. It is small and readable, it hands packaging to electron-builder through a single electron-builder.json, and it spends its complexity budget on the Vite integration instead. If your hard problem is producing installers for several platforms, Forge addresses it directly and this boilerplate does not.

Tauri is a different answer to the same question. It keeps the frontend you already have and replaces the runtime with a Rust core and the operating system's webview, which changes the binary size and the memory profile. electron-vite-vue stays on Electron, which means you ship a Chromium runtime and get consistent rendering across platforms in exchange. The trade is real in both directions, and the deciding factor is usually whether you need the exact same webview everywhere or whether you would rather not bundle one.

Within the Electron world there is also the React sibling, electron-vite-react, which the README links to for its debug animation. The architecture is the same; only the renderer framework differs. If your team writes Vue, this repository is the one to start from.

Licence, maintenance and upgrade cost

The project is MIT licensed, and package.json carries "license": "MIT" with "private": true, which means the package itself is not published for consumption as a dependency. You clone it or use it as a template rather than installing it from a registry. MIT terms are permissive and place few conditions on redistribution, but the boilerplate bundles Electron, Vue, Vite and electron-builder, each under its own licence, so the notices you ship are a function of your dependency tree rather than of this repository alone. That is a packaging question for your own legal review, not something the README settles.

Upgrade cost is the practical concern. The devDependencies in the current package.json pin major versions of electron, vite and typescript, and the release tags have not moved since v28.0.0. Because there is no release cadence to follow, upgrading means diffing the main branch against your fork and reconciling by hand. Projects that treat the clone as a starting point and then diverge will find that cheap. Projects that expect to pull updates will find it expensive, and the README does not describe an upgrade path or a rollback procedure.

Editorial conclusion

Adopt electron-vite-vue if you want a small Electron + Vue 3 + Vite base you can read end to end, and you are willing to wire routing, state and packaging choices yourself. Do not adopt it if you need a maintained release cadence, since the newest release is v28.0.0 from 2024-04-18, or if you want a framework that decides your project layout for you. Before committing, run npm install and npm run dev on your target OS, then run npm run build to confirm electron-builder produces an installer for your platform.

Frequently asked questions

What does Vite do for Vue in electron-vite-vue?

Vite serves the renderer during development and builds it for production, and the boilerplate's dev script runs vite directly. The repository also uses vite-plugin-electron and vite-plugin-electron-renderer to build the main and preload entries and to polyfill Electron and Node APIs for the renderer.

Does electron-vite-vue support Node.js APIs in the renderer?

The README states that the renderer preset in vite.config.ts is a Vite adapter that polyfills Electron, Node.js APIs and native modules for the renderer process. It adds that this is not the same as enabling Node integration, and that direct Node.js access requires nodeIntegration in the BrowserWindow webPreferences in the main process.

How do I install and start electron-vite-vue?

Clone the repository, enter the directory, run npm install, then run npm run dev. The README's Quick Setup lists exactly those four steps, and the dev script maps to vite.

Does electron-vite-vue include routing or state management?

No. The README documents the directory structure, the renderer preset and native addon support, and it does not mention routing, state management, auto-update or testing, so those are choices you make yourself.

What does npm run build do in electron-vite-vue?

The build script runs vue-tsc --noEmit, then vite build, then electron-builder. Packaging settings live in electron-builder.json at the repository root.

Official sources

  1. electron-vite/electron-vite-vue on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/electron-vite-electron-vite-vue.svg)](https://hysenlabs.com/projects/electron-vite-electron-vite-vue)