Create the Electron Forge project

Electron Forge gives us development, packaging, installers, and publishing in one project. Let’s create the app with its Webpack template:

npx create-electron-app@latest desktop-notes --template=webpack
cd desktop-notes
npm start

A small Electron window opens with a “Hello World” page. That’s our app. Keep the terminal running while you work, because Forge rebuilds the app when source files change.

The @latest tag asks npm for the current version of the generator. The generated package.json records the exact Electron and Forge versions the project uses, so the project won’t silently move to a new Electron when you reinstall.

You can see those versions with:

npm ls electron @electron-forge/cli

Keep the generated lockfile and commit it. The generator version alone is not enough to reproduce the project later, because dependency ranges resolve differently over time.

Two runtimes, one project

In the previous lesson I said the app bundles its own Node.js. Let’s see it. Add this line to src/index.js:

console.log(process.versions)

The output appears in the terminal, not in the window. Compare the node field with node --version from your shell. They can differ, and that’s expected.

Now open DevTools in the app window. The template opens them for you in development. In the console, type:

typeof require

You get 'undefined'. The page has no Node.js. This is our first visible process boundary, and the rest of the course is built around it.

Two habits worth starting now

Commit the generated project before you change anything. When an experiment goes wrong, you get a clean point to diff against instead of guessing what the template looked like.

Stop npm start with Ctrl+C and run it again once, just to see how it feels. Hot rebuilding is handy for interface changes. But changes to the main process lifecycle or to the preload script often need a full restart before you can trust what you see. When something behaves strangely later in the course, restart first, then debug.