Secure boilerplate for Electron app based on Vite. TypeScript + Vue/React/Angular/Svelte/Vanilla
MIT License
[!Important] This project is mainrained by developer from Ukraine πΊπ¦
Due to the ongoing war resulting from Russia's full-scale invasion of Ukraine, I currently lack the time for the full development of this open-source project. My primary focus is on ensuring the well-being of myself and my family. I'll prioritize and review all new contributions as soon as possible.
If you can, please consider supporting Ukraine or me personally.
Thank you for your understanding and support.
This is a template for secure electron applications. Written following the latest safety requirements, recommendations and best practices.
Under the hood is Vite β A next-generation blazing fast bundler, and electron-builder for packaging.
Follow these steps to get started with the template:
.github/workflows
since npm is used as default. (See also https://github.com/cawa-93/vite-electron-builder/issues/944)
Note: This template configured to install
peerDependencies
automatically.
That's all you need. π
β€οΈ If you like this template, don't forget to give a β or send support!
.env
files. You can also specify the types oftypes/env.d.ts
.Main
and Renderer
processes.Vite provides many useful features, such as: TypeScript
, TSX/JSX
, CSS/JSON Importing
, CSS Modules
, Web Assembly
and much more.
tests
directory and use playwright.main
branch, the release
workflow starts, which creates a new draft release. For each next commit will be created and replaced artifacts. That way you will always have draft with latest artifacts, and the release can be published once it is ready.
release
workflow.Note: This template configured only for GitHub public repository, but electron-builder also supports other update distribution servers. Find more in electron-builder docs.
The template requires a minimum amount dependencies. Only Vite is used for building, nothing more.
The structure of this template is very similar to a monorepo. The entire source code of the project is divided into three modules (packages) that are each bundled independently:
packages/renderer
. Responsible for the contents of the application window. In fact, it is apackages/preload
. Contain Electron preload scripts. Acts as an intermediate bridge between the renderer process and the APIpackages/main
Schematically, the structure of the application and the method of communication between packages can be depicted as follows:
flowchart TB;
packages/preload <-. IPC Messages .-> packages/main
subgraph packages/main["packages/main (Shared beatween all windows)"]
M[index.ts] --> EM[Electron Main Process Modules]
M --> N2[Node.js API]
end
subgraph Window["Browser Window"]
subgraph packages/preload["packages/preload (Works in isolated context)"]
P[index.ts] --> N[Node.js API]
P --> ED[External dependencies]
P --> ER[Electron Renderer Process Modules]
end
subgraph packages/renderer
R[index.html] --> W[Web API]
R --> BD[Bundled dependencies]
R --> F[Web Frameworks]
end
end
packages/renderer -- Call Exposed API --> P
The main
and preload
packages are built in library mode as it is
simple javascript.
The renderer
package builds as a regular web app.
The next step is to package a ready to distribute Electron app for macOS, Windows and Linux with "auto update" support out of the box.
To do this, use electron-builder:
compile
: This script is configured to compile the application as quickly as possible. It is notBecause the renderer
works and builds like a regular web application, you can only use dependencies that support the
browser or compile to a browser-friendly format.
This means that in the renderer
you are free to use any frontend dependencies such as Vue, React, lodash, axios and so
on. However, you CANNOT use any native Node.js APIs, such as, systeminformation
. These APIs are only available in
a Node.js runtime environment and will cause your application to crash if used in the renderer
layer. Instead, if you
need access to Node.js runtime APIs in your frontend, export a function form the preload
package.
All dependencies that require Node.js api can be used in
the preload
script.
Here is an example. Let's say you need to read some data from the file system or database in the renderer.
In the preload context, create a function that reads and returns data. To make the function announced in the preload
available in the render, you usually need to call
the electron.contextBridge.exposeInMainWorld
. However,
this template uses the unplugin-auto-expose plugin, so you just need
to export the method from the preload. The exposeInMainWorld
will be called automatically.
// preload/index.ts
import { readFile } from 'node:fs/promises';
// Encapsulate types if you use typescript
interface UserData {
prop: string
}
// Encapsulate all node.js api
// Everything you exported from preload/index.ts may be called in renderer
export function getUserData(): Promise<UserData> {
return readFile('/path/to/file/in/user/filesystem.json', {encoding:'utf8'}).then(JSON.parse);
}
Now you can import and call the method in renderer
// renderer/anywere/component.ts
import { getUserData } from '#preload'
const userData = await getUserData()
Find more in Context Isolation tutorial.
Although the preload has access to all of Node.js's API, it still runs in the BrowserWindow context, so a limited electron modules are available in it. Check the electron docs for full list of available methods.
All other electron methods can be invoked in the main
.
As a result, the architecture of interaction between all modules is as follows:
sequenceDiagram
renderer->>+preload: Read data from file system
preload->>-renderer: Data
renderer->>preload: Maximize window
activate preload
preload-->>main: Invoke IPC command
activate main
main-->>preload: IPC response
deactivate main
preload->>renderer: Window maximized
deactivate preload
Find more in Inter-Process Communication tutorial.
All environment variables are set as part of the import.meta
, so you can access them vie the following
way: import.meta.env
.
Note: If you are using TypeScript and want to get code completion you must add all the environment variables to the
ImportMetaEnv
intypes/env.d.ts
.
The mode option is used to specify the value of import.meta.env.MODE
and the corresponding environment variables files
that need to be loaded.
By default, there are two modes:
production
is used by defaultdevelopment
is used by npm run watch
scriptWhen running the build script, the 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
Warning: To prevent accidentally leaking env variables to the client, only variables prefixed with
VITE_
are exposed to your Vite-processed code.
For example let's take the following .env
file:
DB_PASSWORD=foobar
VITE_SOME_KEY=123
Only VITE_SOME_KEY
will be exposed as import.meta.env.VITE_SOME_KEY
to your client source code, but DB_PASSWORD
will not.
You can change that prefix or add another. See envPrefix
See Contributing Guide.