Skip to content

React version of cawa-93's secure boilerplate for Electron apps with Vite and TypeScript.

License

Notifications You must be signed in to change notification settings

james-elicx/vite-electron-builder-react

Β 
Β 

Repository files navigation

Vite Electron Builder React Boilerplate


Based on soulsam480's React fork of the Vite Electron Builder Boilerplate by cawa-93.

Features changes to project structure, minor bug fixes, extra CI/CD functionality, more ESLint & Prettier, React, and Sass.

CI/CD

Continuous Integration

  • For each push and pull-request, the workflow runs the following.

    • Check the types.
    • Check the code style.
    • Run automatic tests using Vitest.
      • Unit tests are placed within each package and run separately.
      • End-to-end tests are placed in the root tests directory and use playwright.

Continuous Delivery

  • The release workflow runs when you push to the main branch, creating a release draft.

    • To skip the compile and release phase of the release workflow, your commit message to the main branch must include [skip] or skip cd or cd skip.
    • Release versions are based on the current date and time using the format yy.mm.dd-minutes.
    • Notes are generated using commit messages that occured since the last release.
  • Code signing, notarization, and releasing to Snapcraft are all supported. See below.

  • Auto-update is supported. After you publish the release, all client applications will download the new version and install updates silently.

You can define which operating systems you want to build releases for in .github/workflows/release.yml.

strategy:
  matrix:
    # To compile the application for different platforms, change the array
    # Options: macos-latest, ubuntu-latest, windows-latest
    os: [windows-latest]

Code Signing

Building for Windows
  1. Export your Extended Validation code signing certificate into a single file (e.g. certs.p12).
  2. Base64 encode your certificates with the base64 -i certs.p12 -o encoded.txt command.
  3. Define some secrets in the repository settings on GitHub.
    • windows_certs - Your encoded certificates, i.e. the content of the encoded.txt file you created before.
    • windows_certs_password - The password you set when exporting the certificates.
  4. Uncomment the Windows code signing certificate code in .github/workflows/release.yml.
# Base64-encoded code signing certificate for Windows
windows_certs: ${{ secrets.windows_certs }}

# Password for decrypting `windows_certs`
windows_certs_password: ${{ secrets.windows_certs_password }}
Building for MacOS
  1. Export your code signing certificates from the Keychain Access app or the Apple Developer Portal into a single file (e.g. certs.p12).
  2. Base64 encode your certificates with the base64 -i certs.p12 -o encoded.txt command.
  3. Define some secrets in the repository settings on GitHub.
    • mac_certs - Your encoded certificates, i.e. the content of the encoded.txt file you created before.
    • mac_certs_password - The password you set when exporting the certificates.
  4. Uncomment the MacOS code signing certificate code in .github/workflows/release.yml.
# Base64-encoded code signing certificate for macOS
mac_certs: ${{ secrets.mac_certs }}

# Password for decrypting `mac_certs`
mac_certs_password: ${{ secrets.mac_certs_password }}

Notarization (MacOS)

  1. Create an API key with the App Manager access permissions and download the key file.
  2. Define some secrets in the repository settings on GitHub.
    • apple_api_key - Content of the API key file (with the p8 file extension).
    • apple_api_key_id - Key ID found on App Store Connect.
    • apple_api_key_issuer_id - Issuer ID found on App Store Connect.
  3. Uncomment the MacOS notarization code in .github/workflows/release.yml.
# If building a release for macos, need to do notarization.
- name: Prepare for app notarization
  if: startsWith(matrix.os, 'macos')
  # Import Apple API key for app notarization on macOS
  run: |
    mkdir -p ~/private_keys/
    echo '${{ secrets.apple_api_key }}' > ~/private_keys/AuthKey_${{ secrets.api_key_id }}.p8
# macOS notarization API key
API_KEY_ID: ${{ secrets.apple_api_key_id }}
API_KEY_ISSUER_ID: ${{ secrets.apple_api_key_issuer_id }}

Releasing to Snapcraft (Linux)

  1. Retrieve a Snapcraft token by following the steps here.
  2. Define some secrets in the repository settings on GitHub.
    • snapcraft_token - Snapcraft token retrieved in the previous step.
  3. Uncomment the Snapcraft code in .github/workflows/release.yml.
# If releasing Linux app to Snapcraft, install and sign in.
- name: Install Snapcraft
  uses: samuelmeuli/action-snapcraft@v1
  # Only install Snapcraft on Ubuntu
  if: startsWith(matrix.os, 'ubuntu')
  with:
    # Log in to Snap Store
    snapcraft_token: ${{ secrets.snapcraft_token }}

GitHub issues by-label Required Node.JS >= v16.13 Required npm >= v8.1

Vite+Electron = πŸ”₯

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

Under the hood is used Vite β€” superfast, 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

Follow these steps to get started with this template:

  1. Click the Use this template button (you must be logged in) or just clone this repo.
  2. If you want to use another package manager don't forget to edit .github/workflows -- it uses npm by default.

That's all you need. πŸ˜‰

Note: This template uses npm v7 feature β€” Installing Peer Dependencies Automatically. If you are using a different package manager, you may need to install some peerDependencies manually.

Note: Find more useful forks here.

Features

Electron Electron version

  • This template uses the latest electron version with all the latest security patches.
  • The architecture of the application is built according to the security guides and best practices.
  • The latest version of the electron-builder is used to compile the application.

Vite Vite version

  • 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. You can also specify types of your environment variables in types/env.d.ts.
  • Hot reloads for Main and Renderer processes.

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

See all Vite features.

TypeScript TypeScript version (optional)

  • The latest version of TypeScript is used for all the 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.

See this discussion if you want completely remove TypeScript.

Vue Vue version (optional)

  • By default, web pages are built using Vue. However, you can easily change that. Or not use additional frameworks at all.
  • 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 will check the types for each push and PR.
  • The configured workflow will check the code style for each push and PR.
  • Automatic tests used Vitest Vitest version -- A blazing fast test framework powered by Vite.
    • Unit tests are placed within each package and run separately.
    • End-to-end tests are placed in the root tests directory and use playwright.

Continuous delivery

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

How it works

The template requires a minimum amount 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 each bundled independently:

Build web resources

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

Compile App

The next step is to package and compile a ready to distribute Electron app for macOS, Windows and Linux with "auto update" support out of the box.

To do this using the electron-builder:

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

Working with dependencies

There is one important nuance when working with dependencies. At the build stage Vite will analyze your code, find all the imported dependencies, apply tree shaking, optimize and bundle them inside the output source files. So when you write something like this:

// source.ts
import { createApp } from 'vue';
createApp();

It turns into:

// bundle.js
function createApp() {
  /* ... */
}
createApp();

Which leaves basically no imports during runtime.

But it doesn't always work. Vite was designed to work with browser-oriented packages. So it is not able to bundle Node built-in modules, or native dependencies, or some Node.js specific packages, or Electron itself.

Modules that Vite is unable to bundle are forced to be supplied as external in vite.config.js. External modules are not optimized and their imports remain during runtime.

// source.ts
import { writeFile } from 'fs';
writeFile();

// bundle.js
const { writeFile } = require('fs');
writeFile();

Using external modules in renderer

According to Electron's security guidelines, Node.js integration is disabled for remote content. This means that you cannot call any Node.js api in the packages/renderer directly. This also means you can't import external modules during runtime in the renderer:

// renderer.bundle.js
const { writeFile } = require('fs'); // ReferenceError: require is not defined
writeFile();

To use external modules in Renderer you must describe the interface in the packages/preload where the Node.js api is allowed:

// packages/preload/src/index.ts
import { type BinaryLike, createHash } from 'crypto';
import { exposeInMainWorld } from './exposeInMainWorld';

exposeInMainWorld('nodeCrypto', {
  sha256sum(data: BinaryLike) {
    const hash = createHash('sha256');
    hash.update(data);
    return hash.digest('hex');
  },
});

If you use a TypeScript you must add the signature of your method to the contracts:

// packages/preload/contracts.d.ts
interface Exposed {
  nodeCrypto: {
    sha256sum(data: import('crypto').BinaryLike): string;
  };
}

And now, you can safely use the registered method:

// packages/renderer/src/App.vue
window.nodeCrypto.sha256sum('data');

As a result, the architecture of interaction between all modules is as follows:

flowchart LR;
R --> W[Web API]
R --> BD[Bundled dependencies]
R[Renderer] -- Call Exposed API --> P[Preload] --> N[Node.js API]
P --> ED[External dependencies]
P --> ER[Electron Renderer Process Modules]
P <-. IPC Messages .-> M[Main] --> EM[Electron Main Process Modules]

Read more about Security Considerations.

Modes and Environment Variables

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

If you are using TypeScript and want to get code completion you must add all the environment variables to the ImportMetaEnv in types/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 default
  • development is used by npm run watch script

When 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

To prevent accidentally leaking env variables to the client, only variables prefixed with VITE_ are exposed to your Vite-processed code. e.g. the following 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.

Contribution

See Contributing Guide.

About

React version of cawa-93's secure boilerplate for Electron apps with Vite and TypeScript.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • TypeScript 94.8%
  • JavaScript 2.7%
  • HTML 1.6%
  • SCSS 0.9%