Vite Electron Builder Boilerplate v2

Vite+Electron = 🔥

This is a secure template for electron applications. Written following the latest safety requirements, recommendations and best practices.

Under the hood is used Vite — super fast, nextgen bundler, and electron-builder for compilation.

---

Support

• This template maintained by Alex Kozack. You can 💖 sponsor him for continued development of this template.

• Found a problem? Pull requests are welcome.

• If you have ideas, questions or suggestions - Welcome to discussions. 😊

---

Get started

Requirements

• node: >= v14
• npm: >= v7.7

Installation

Follow these steps to get started with this template:

1. Click the Use this template button.

   Note: Only the main branch matters. You do not need to include any other branches when creating the repository.

That's all you need. 😉

Features

Electron

• Template use the latest electron version with all the latest security patches.
• The architecture of the application is built according to the security guids and best practices.
• The latest version of the electron-builder is used to compile the application.

Vite

• Vite is used to bundle all source codes. This is an extremely fast packer that has a bunch of great features. You can learn more about how it is arranged in this video.
• Vite supports reading .env files. My template has a separate command to generate .d.ts file with type definition your environment variables.

Vite provides you with many useful features, such as: TypeScript, TSX/JSX, CSS/JSON Importing, CSS Modules, Web Assembly and much more.

See all Vite features.

TypeScript (optional)

• The Latest TypeScript is used for all source code.
• Vite supports TypeScript out of the box. However, it does not support type checking.
• Code formatting rules follow the latest TypeScript recommendations and best practices thanks to @typescript-eslint/eslint-plugin.

Note: If you do not need a TypeScript, you can easily abandon it. To do this, You do not need to make any bundler configuration changes, etc. Just replace all .ts files with .js files. Additionally, it will be useful to delete TS-specific files, plug-ins and dependencies like tsconfig.json, @typescript-eslint/*, etc.

Vue (optional)

• By default, web pages are built using Vue. However, you can easily change it. Or do not use additional frameworks at all. (See React fork)
• Also, by default, the vue-router version is used.
• Code formatting rules follow the latest Vue recommendations and best practices thanks to eslint-plugin-vue.
• Installed Vue.js devtools beta with Vue 3 support.

See examples of web pages for different frameworks.

Continuous Integration

• The configured workflow for check the types for each push and PR.
• The configured workflow for check the code style for each push and PR.
• Automatic tests used spectron. Simple, automated test check:
  • Does the main window created and visible?
  • Is the main window not empty?
  • Is dev tools closed?

Continuous delivery

• Each time you push changes to the main branch, release workflow starts, which creates release draft.
  • The version is automatically set based on the current date in the format "yy.mm.dd".
  • Notes are automatically generated and added to the release draft.
  • Code signing supported. See compile job in release workflow.
• Auto-update is supported. After the release will be published, all client applications will download the new version and install updates silently.

Status — WIP

This template was created to make my work easier. It may not be universal, but I try to keep it that way.

I am actively involved in its development. But I do not guarantee that this template will be maintained in the future.

At the moment, there are the following problems:

• ⚠ Some files require refactoring.
• ⚠ Watch mode for the main and preload entry points should be improved. Blocked by vite#1434.
• ⚠ Typechecking renderer package in CI implemented by , which has a very early version. This is not a problem if you do not use Vue or TypeScript.
• ⚠ Release notes are created automatically based on commit history. scripts/release-notes.js is used for generation. It may not provide some scenarios. If you encounter a problem - write about it.
• ⏳ I want to migrate all code base to ESM. But because Nodejs ecosystem is unprepared I not known whether this will give more benefits or more inconvenience.

Some improvement or problems can be listed in issues.

Pull requests are welcome.

How it works

The template required a minimum dependencies. Only Vite is used for building, nothing more.

Project Structure

The structure of this template is very similar to the structure of a monorepo.

The entire source code of the program is divided into three modules (packages) that are bundled each independently:

• packages/main Electron main script.
• packages/preload Used in BrowserWindow.webPreferences.preload. See Checklist: Security Recommendations.
• packages/renderer Electron web page.

Build web resources

Packages main and preload are built in library mode as it is a simple javascript. renderer package build as regular web app.

The build of web resources is performed in the scripts/build.js. Its analogue is a sequential call to vite build for each package.

Compile App

Next step is run packaging and compilation a ready for distribution Electron app for macOS, Windows and Linux with "auto update" support out of the box.

To do this, using the electron-builder:

• In npm script compile: This script is configured to compile the application as quickly as possible. It is not ready for distribution, is compiled only for the current platform and is used for debugging.
• In GitHub Action: The application is compiled for any platform and ready-to-distribute files are automatically added to the draft GitHub release.

Using electron API in renderer

As per the security requirements, context isolation is enabled in this template.

Context Isolation is a feature that ensures that both your preload scripts and Electron's internal logic run in a separate context to the website you load in a webContents. This is important for security purposes as it helps prevent the website from accessing Electron internals, or the powerful APIs your preload script has access to.

This means that the window object that your preload script has access to is actually a different object than the website would have access to. For example, if you set window.hello = 'wave' in your preload script and context isolation is enabled window.hello will be undefined if the website tries to access it.

Read more about Context Isolation.

Exposing APIs from your preload script to the renderer is a common use case and there is a dedicated module in Electron to help you do this in a painless way.

// packages/preload/src/index.ts
const api = {
  data: ['foo', 'bar'],
  doThing: () => ipcRenderer.send('do-a-thing')
}

contextBridge.exposeInMainWorld('electron', api)

To access this API use the useElectron() function:

// packages/renderer/src/App.vue
import {useElectron} from '/@/use/electron'

const {doThing, data} = useElectron()

Note: Context isolation disabled for test environment. See #693.

Modes and Environment Variables

All environment variables set as part of the import.meta, so you can access them as follows: import.meta.env.

You can also build type definitions of your variables by running scripts/buildEnvTypes.js. This command will create types/env.d.ts file with describing all environment variables for all modes.

The mode option is used to specify the value of import.meta.env.MODE and the corresponding environment variables files that needs to be loaded.

By default, there are two modes:

• production is used by default
• development is used by npm run watch script
• test is used by npm test script

When running building, environment variables are loaded from the following files in your project root:

.env                # loaded in all cases
.env.local          # loaded in all cases, ignored by git
.env.[mode]         # only loaded in specified env mode
.env.[mode].local   # only loaded in specified env mode, ignored by git

Note: only variables prefixed with VITE_ are exposed to your code (e.g. VITE_SOME_KEY=123) and SOME_KEY=123 will not. you can access VITE_SOME_KEY using import.meta.env.VITE_SOME_KEY. This is because the .env files may be used by some users for server-side or build scripts and may contain sensitive information that should not be exposed in code shipped to browsers.

Contribution

See Contributing Guide.