Foundations and setup

Prepare the toolchain

Install a current Node.js release, Git, and the operating-system tools needed to build Electron applications.

We will use Electron Forge to create, run, and package the project. Forge’s current tooling uses Node.js 22 as the minimum supported baseline, so that’s the first thing to check.

Run these three commands:

node --version
npm --version
git --version

You want a Node.js version starting with v22 or higher, and a version number back from the other two. If node is missing or too old, install the current LTS release from the Node.js website and run the check again.

Two different Node.js versions

Your development Node.js runs npm, Forge, and the build scripts. The packaged Electron app does not use it. Electron ships its own Node.js runtime, bundled inside the application.

Those two versions can differ. Later we will log process.versions from inside the app to see the bundled one. Don’t assume it matches node --version from your terminal.

Operating-system tools

Packaging uses tools from each operating system.

On macOS, install the Xcode command-line tools:

xcode-select --install

On Windows, use PowerShell or Command Prompt for the course commands. On Linux, install the build packages your distribution suggests if a maker asks for them during packaging.

Native modules

Some npm packages contain native code compiled for a specific Node.js version. Electron bundles a different Node.js, so those modules must be rebuilt for Electron’s application binary interface, the contract between compiled code and the runtime.

Forge handles the common rebuild steps. But a module that works in plain Node.js can still fail inside Electron. Desktop Notes uses no native modules, so we avoid the problem entirely. Be careful when you add one to a real app.

Where to put the project

Create a normal development folder on your local disk. Do not build the project inside a cloud-synchronized folder like iCloud Drive or Dropbox, and not on a network mount. Packaging creates thousands of files, and sync tools fight with that.

Then record the versions you just checked in a small TESTING.md file at the root of the project. Three lines are enough. When packaging fails on another machine in three months, that baseline tells you right away whether the toolchain changed or the code did.

Lesson completed