Disabled modules in MAS build
The following modules are disabled in the MAS build of Electron: crashReporter and autoUpdater.
Electron · Tutorial · all subjects
packaging
107 notes in this subject, read out of this brain and free to use. This is page 2 of 2.
Behavioral changes in MAS build
In the MAS build of Electron, video capture may not work for some machines, certain accessibility features may not work, and apps will not be aware of DNS changes.
Three methods to create .snap file
There are three ways to create a .snap file for Electron applications. First, use Electron Forge or electron-builder, both of which come with snap support out of the box—this is the easiest option. Second, use electron-installer-snap, which takes @electron/packager's output. Third, use an already created .deb package.
electron-installer-snap installation
Install electron-installer-snap with npm: npm install --save-dev electron-installer-snap
electron-installer-snap CLI usage
Run electron-installer-snap from a terminal that has snapcraft in its PATH with the --src parameter: npx electron-installer-snap --src=out/myappname-linux-x64. The --src parameter is required and specifies the location of your packaged Electron application.
electron-installer-snap programmatic usage
Use electron-installer-snap programmatically by requiring the module and calling it with options. The snap function returns a promise that resolves to the path of the created snap file. Example: const snap = require('electron-installer-snap'); snap(options).then(snapPath => console.log(`Created snap at ${snapPath}!`))
snapcraft.yaml structure for @electron/packager
A snapcraft.yaml file for @electron/packager-based packaging includes: name (app name), version (semantic version), summary (short description), description (detailed description), base (core22 or newer), confinement (strict or classic), grade (stable). The apps section contains the app entry with command, extensions (gnome), plugs (browser-support, network, network-bind), and environment variables. TMPDIR must be set to $XDG_RUNTIME_DIR to correct the path for Chromium Framework/Electron and ensure libappindicator has readable resources.
snapcraft.yaml example with @electron/packager
Example snapcraft.yaml configuration using @electron/packager: name: electron-packager-hello-world version: '0.1' summary: Hello World Electron app description: | Simple Hello World Electron app as an example base: core22 confinement: strict grade: stable apps: electron-packager-hello-world: command: my-app/my-app --no-sandbox extensions: [gnome] plugs: - browser-support - network - network-bind environment: TMPDIR: $XDG_RUNTIME_DIR parts: my-app: plugin: nil source: . override-build: | npm install electron @electron/packager npx electron-packager . --overwrite --platform=linux --output=release-build --prune=true cp -rv ./my-app-linux-* $SNAPCRAFT_PART_INSTALL/my-app build-snaps: - node/14/stable build-packages: - unzip stage-packages: - libnss3 - libnspr4
snapcraft build command
Build a snap by running the snapcraft command from the project root where snapcraft.yaml is located: snapcraft
snapcraft.yaml for .deb package conversion
A snapcraft.yaml for converting an existing .deb package includes: name (app name), version (semantic version), summary, description, grade (stable), confinement (classic or strict). The parts section includes the deb package definition with plugin: dump, source pointing to the .deb file, source-type: deb, after and stage-packages for dependencies. The apps section specifies the command to launch with proper TMPDIR and desktop file location.
snapcraft.yaml example for .deb package
Example snapcraft.yaml for converting a .deb package: name: myApp version: '2.0.0' summary: A little description for the app. description: | You know what? This app is amazing! It does all the things for you. Some say it keeps you young, maybe even happy. grade: stable confinement: classic parts: slack: plugin: dump source: my-deb.deb source-type: deb after: - desktop-gtk3 stage-packages: - libasound2 - libnotify4 - libnspr4 - libnss3 - libpcre3 - libpulse0 - libxss1 - libxtst6 electron-launch: plugin: dump source: files/ prepare: | chmod +x bin/electron-launch apps: myApp: command: bin/electron-launch $SNAP/usr/lib/myApp/myApp desktop: usr/share/applications/myApp.desktop environment: TMPDIR: $XDG_RUNTIME_DIR
electron-launch wrapper script for classic confinement
For classic confinement, use a custom electron-launch wrapper script: #!/bin/sh\nexec "$@" --executed-from="$(pwd)" --pid=$$ > /dev/null 2>&1 &
desktop-launch command for strict confinement
For strict confinement, use the desktop-launch command instead of a custom wrapper: command: env TMPDIR=$XDG_RUNTIME_DIR PATH=/usr/local/bin:${PATH} ${SNAP}/bin/desktop-launch $SNAP/myApp/desktop
Enable desktop capture with PipeWire
Capturing the desktop requires PipeWire library in Linux configurations using the Wayland protocol. Use base snap core22 or newer. Create a pipewire part and add it to the after section of your application. Configure the application's environment with SPA_PLUGIN_DIR, PIPEWIRE_CONFIG_NAME, and PIPEWIRE_MODULE_DIR variables.
PipeWire snapcraft.yaml part configuration
Add this pipewire part to snapcraft.yaml for desktop capture support: pipewire: plugin: nil build-packages: [libpipewire-0.3-dev] stage-packages: [pipewire] prime: - usr/lib/*/pipewire-* - usr/lib/*/spa-* - usr/lib/*/libpipewire*.so* - usr/share/pipewire
PipeWire environment variables configuration
Configure PipeWire environment variables in snapcraft.yaml apps section: environment: SPA_PLUGIN_DIR: $SNAP/usr/lib/$CRAFT_ARCH_TRIPLET/spa-0.2 PIPEWIRE_CONFIG_NAME: $SNAP/usr/share/pipewire/pipewire.conf PIPEWIRE_MODULE_DIR: $SNAP/usr/lib/$CRAFT_ARCH_TRIPLET/pipewire-0.3
Remove unnecessary node_modules before packaging
When packaging an Electron application with @electron/packager or similar tools before creating a snap, remove node_modules that are not needed in the final application, since unused modules increase the application's size.
Snap installation with --dangerous flag
Install a snap file using: sudo snap install electron-packager-hello-world_0.1_amd64.snap --dangerous. The --dangerous flag is needed when installing unsigned or self-signed snaps.
Install Electron as devDependency, not production dependency
Electron should be installed in devDependencies because the packaging step for Electron handles bundling of the binary, eliminating the need to specify it as a production dependency. The production code runs Electron APIs, but the binary is bundled during packaging.
Use nodeLinker node-modules for Yarn and pnpm
Electron's packaging toolchain requires the node_modules folder to be physically on disk in the way that npm installs Node dependencies. Set 'nodeLinker: node-modules' in Yarn Berry or 'nodeLinker: hoisted' in pnpm, as both use alternative installation strategies by default.
Electron lacks built-in packaging tooling
Electron does not have any tooling for packaging and distribution bundled into its core modules. Once you have a working Electron app in dev mode, you need to use additional tooling to create a packaged app you can distribute to users.
Distributable formats: installers and portable executables
Distributables can be either installers (e.g. MSI on Windows) or portable executable files (e.g. .app on macOS).
Electron Forge combines multiple packaging tools
Electron Forge is an all-in-one tool that handles the packaging and distribution of Electron apps. Under the hood, it combines existing Electron tools (e.g. @electron/packager, @electron/osx-sign, electron-winstaller, etc.) into a single interface so you do not have to wire them all together.
Install Electron Forge CLI
You can install Electron Forge's CLI in your project's devDependencies using npm install --save-dev @electron-forge/cli or yarn add --dev @electron-forge/cli.
Import project into Electron Forge
After installing Electron Forge CLI, run npx electron-forge import (for npm) or yarn electron-forge import (for Yarn) to convert your existing project. The conversion script adds several scripts to package.json and creates a forge.config.js configuration file.
Electron Forge package.json scripts after import
After importing a project into Electron Forge, the package.json file should contain three new scripts: "start": "electron-forge start", "package": "electron-forge package", and "make": "electron-forge make".
Make command creates distributables
The make command (npm run make) contains two steps: first it runs electron-forge package under the hood to bundle your app code together with the Electron binary into a folder, then it uses this packaged app folder to create a separate distributable for each configured maker. The results are output to an out folder.
Forge configuration creates makers for each platform
The forge.config.js file exports a configuration object with multiple makers (packages that generate distributable app bundles), one for each target platform. Different OS-specific formats can be configured such as DMG, deb, MSI, etc.
Minimum Electron version for Windows ARM
Windows on ARM support requires Electron 6.0.8 or later.
Building ARM app without native modules
To build a Windows ARM app without native modules: 1) ensure the node_modules directory is empty, 2) run 'set npm_config_arch=arm64' in Command Prompt before running npm install or yarn install, 3) npm will download and unpack the arm64 version of Electron if installed as a development dependency, then package and distribute normally.
Testing Windows ARM apps
Test apps on a Windows on ARM device running Windows 10 version 1903 or later. Copy the application to the target device; Chromium's sandbox will not work correctly when loading application assets from a network location.
Windows Store AppX package format and benefits
Electron apps can be compiled as .appx packages for Windows 10, enabling distribution through the Windows Store. The .appx format provides access to Universal Windows Platform APIs such as Cortana and Push Notifications, and simplifies installation and updating compared to traditional win32 executables.
Windows 10 AppX virtualization model
Windows 10 Anniversary Update and later can run win32 .exe binaries within a virtualized filesystem and registry. These virtualized components are created during compilation by running the app and installer inside a Windows Container, allowing Windows to identify exactly which modifications to the operating system occur during installation. This pairing enables one-click installation and uninstallation.
Electron app requirements for Windows Store packaging
To compile an Electron app as a Windows Store package, the following requirements must be met: Windows 10 with Anniversary Update (released August 2, 2016), the Windows 10 SDK, and Node 4 or later.
electron-windows-store CLI installation
Install the electron-windows-store command-line tool globally using npm: npm install -g electron-windows-store
Step 1: Package Electron application before AppX conversion
Before converting to AppX, package the Electron application using a tool like @electron/packager. Ensure to remove any unnecessary node_modules from the final application, as unused modules increase the application size. The packaged output should include the main executable, DLL files, pak files, resources folder with app.asar, and locales.
electron-windows-store command-line parameters
Run electron-windows-store from an elevated PowerShell with the following parameters: --input-directory (path to packaged Electron app), --output-directory (where to create AppX package), --package-version (version number like 1.0.0.0), and --package-name (app name).
electron-windows-store processing steps
The electron-windows-store CLI performs the following steps: flattens node_modules, archives the application as app.zip, uses a Windows Container and installer to create an expanded AppX package including AppXManifest.xml and virtual filesystem/registry components, uses Windows App Packager (MakeAppx.exe) to create a single-file AppX package, creates a trusted certificate to sign the package, and can automatically install the signed package on the machine.
AppX package platform limitations
Compiled AppX packages still contain a win32 executable and will not run on Xbox, HoloLens, or mobile phones, limiting their platform availability despite the UWP wrapper.
Automated AppX package installation in enterprises
In managed environments like enterprises, the PowerShell Cmdlet Add-AppxPackage can be used to install AppX packages in an automated fashion, rather than requiring manual double-click installation.
Optional: AppX with UWP background task
Electron apps can be paired with an invisible UWP background task to gain full access to Windows 10 features including push notifications, Cortana integration, and live tiles. This allows the app to receive push notifications and communicate with other UWP applications.
Container virtualization for AppX generation
The electron-windows-store CLI includes an optional container virtualization mode that uses a Windows Container to compile AppX packages. This mode installs and runs the application in a blank Windows Container to determine exactly what modifications the application makes to the operating system. This method is useful when the standard template approach fails or a custom installer is used.
Desktop App Converter setup for container virtualization
Before using container virtualization with electron-windows-store, setup the Desktop App Converter: download DesktopAppConverter.zip and BaseImage-14316.wim, unzip DesktopAppConverter.zip, run Set-ExecutionPolicy bypass in elevated PowerShell, then run .\DesktopAppConverter.ps1 -Setup -BaseImage .\BaseImage-14316.wim. A reboot may be required. This setup only needs to be done once.
macOS Electron build prerequisites
To build Electron on macOS, you need: macOS >= 12, Xcode (exact version depends on branch being built), Python >= 3.9, and Node.js >= 22.12.0.
Rosetta 2 for arm64 macOS builds
When building Electron on arm64 macOS machines, Rosetta 2 is recommended if using dependencies that need to cross-compile on both x64 and arm64. Install Rosetta 2 using: softwareupdate --install-rosetta
Fix Xcode incompatible architecture error on arm64
On arm64 macOS, if the build script points to the wrong Xcode version (e.g., 11.x.y which doesn't support arm64), navigate to /Users/<user>/.electron_build_tools/third_party/Xcode/ and rename Xcode-13.3.0.app to Xcode.app to ensure the correct Xcode version is used.
Python SSL certificate verification error during Electron build
If SSL certificate verification fails during the build (particularly when downloading clang tools), install the certifi Python package. The error occurs because Python 3.6 uses its own copy of OpenSSL instead of the deprecated Apple-supplied OpenSSL libraries. The certifi package adds a curated bundle of default root certificates.