angular-electron: an Angular 22 and Electron 44 starter with two package.json files

The problem: wiring an Angular renderer to an Electron main process

Starting an Angular desktop app means solving several problems at once. The renderer needs a dev server with hot reload. The main process needs its own TypeScript compilation. The packager needs a dependency tree that excludes the Angular toolchain from the shipped bundle. angular-electron answers all three with a working configuration rather than a description of one.

The README frames the scope plainly: bootstrap and package your project with Angular 22 and Electron 44, TypeScript, SASS and hot reload. The sample runs Angular v22.1.4 and Electron v44.1.1, and the repository's package.json declares version 22.1.0. It is aimed at developers who already know Angular and want the desktop shell handled, not at people learning either framework. The README's own list of what you can do is short: run in development with hot reload, run in production, execute tests with Vitest and Playwright, and package an executable for Linux, Windows and Mac.

Two package.json files and the app/ versus src/ split

The architecture is visible in the repository layout. The app folder holds the Electron main process in NodeJS, and src holds the renderer process, which is the Angular application. The README points at app/main.ts as the entry that manages the application code, and notes that the sample runs an Angular app on http://localhost:4200 alongside an Electron window.

The reason there are two package.json files is the Electron Builder two package structure. The README says this optimizes the final bundle while keeping the Angular ng add feature usable. In practice that means the root manifest carries the Angular toolchain and web dependencies, while app/package.json carries what the main process needs. The README is explicit that the final bundle contains only the /dist folder and NodeJS dependencies.

That split creates a rule you have to follow. NodeJS libraries that use core modules such as crypto, fs or util should be added to the dependencies of both app/package.json and the root package.json, so they resolve in the main process and the renderer. Web libraries such as bootstrap, material or tailwind go only in the root manifest. The README points to providers/electron.service.ts as the place to see how conditional imports work in the renderer context. This is the part most people get wrong, and the README treats it as a warning rather than a footnote.

Install and first run

Clone the repository, then install the root dependencies, which the README says are used by the Electron renderer process.

git clone https://github.com/belnadris/angular-electron.git
npm install

The README states there is an issue with yarn and node_modules when the application is built by the packager, and asks you to use npm as the dependency manager. If you want to generate Angular components with the Angular CLI, install it globally.

npm install -g @angular/cli

The Electron main process has its own dependency root, so change into app/ and install again.

cd app/
npm install

With both installs done, npm start runs the development setup. The script uses concurrently to run electron:serve and ng:serve together, and electron:serve waits on tcp:4200 before compiling and launching Electron. You should see the Angular app in a browser at http://localhost:4200 and the same app inside an Electron window. The README notes you can disable Developer Tools by commenting out win.webContents.openDevTools(); in app/main.ts.

If you only want the browser, npm run ng:serve:web runs the app with hot reload in the browser. When you are ready to ship, npm run electron:build builds the production web output and runs electron-builder with --publish=never. On Linux the README says that command produces both an AppImage and a Flatpak, and the Flatpak path needs extra tooling installed first.

Hot reload stops at the process boundary

The README carries an explicit warning: hot reload only pertains to the renderer process. The main Electron process cannot be hot reloaded, only restarted. That is a real limit on the workflow. Any change in app/main.ts, including window options, IPC handlers or native library wiring, costs you a restart of the Electron process. Angular component and template edits reload normally.

The two package.json structure is the second cost. Adding a Node-only library means editing two manifests and running installs in two directories. The README also warns that ng-add may be difficult because the project does not use the default @angular-builders, and points to HOW_TO.md for a worked example of installing Angular Material. If your team expects ng add to just work, budget time for that file.

The README does not document rollback procedures, migration steps between major versions, or what happens to a packaged app when the Electron version changes. It also does not describe a production update mechanism. For a starter template that is normal, but it means the upgrade path is yours to design.

Testing and packaging commands you will actually run

Tests are split by layer. Unit tests run through the Angular test target with npm test, which the package.json defines as ng test --watch=false, and npm run test:watch leaves the watcher on. End-to-end tests live in the e2e folder and run through Playwright.

npm run e2e

The e2e script builds the production web output first, then invokes playwright test with the config at e2e/playwright.config.ts. The README notes a proxy caveat: behind a proxy you may need to export {no_proxy,NO_PROXY}="127.0.0.1,localhost" in your terminal for the tests to reach the local app. A trace viewer is wired up through npm run e2e:show-trace.

For packaging, npm run electron:build is the single entry point. The README's included-commands table also lists npm run electron:local, which builds the application and starts Electron locally without the full packaging step. If you need a specific library in the main thread, the README says to import it in the dependencies section of app/package.json with npm install --save XXXXX, and then import it in app/main.ts.

How it compares with Electron Forge and a plain Angular CLI setup

Electron Forge is the other common starting point, and it appears in the related search terms around this project. The difference is who owns the build pipeline. Forge provides its own plugin system for bundling, packaging and publishing, and it expects to manage the toolchain around your app. angular-electron instead keeps the Angular CLI in charge of the renderer build and adds electron-builder for packaging, with the two package.json structure as the seam between them. If you want one tool that owns the whole desktop lifecycle, Forge is the closer fit. If you want the Angular CLI workflow you already know, this repository does not fight it.

The second comparison is doing it yourself on top of a plain Angular CLI project. That path gives you full control and no two-manifest rule, but you write the main-process TypeScript config, the wait-on orchestration, the electron-builder config and the Playwright setup. The repository includes tsconfig.serve.json, electron-builder.json and e2e/playwright.config.ts so none of that is left to you. The cost is inheriting decisions someone else made, including the npm-only stance and the ng-add friction.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-04. Release 22.1.0 landed the same day, 22.0.1 on 2026-08-08, and 17.1.0 on 2026-03-02. The version numbers track the Angular major, so 22.1.0 corresponds to the Angular 22 line the README describes. A version bump is therefore not a small patch: moving to a new Angular major means a new repository release, and the postversion script in package.json copies the root version into app/package.json, which tells you the two manifests are meant to stay in step.

Upgrade cost is dominated by three files. angular.json governs the renderer build, tsconfig.serve.json governs the main-process compilation, and electron-builder.json governs packaging. The README does not describe a migration procedure for any of them, so plan to diff them against the upstream repository when you upgrade. The .node-version file pins the Node version the project expects, and the README's Flatpak instructions reference org.freedesktop.Platform//25.08, org.freedesktop.Sdk//25.08 and org.electronjs.Electron2.BaseApp//25.08 runtimes, which you install yourself.

The licence is MIT, declared in the header badge and the LICENSE.md file. That is permissive and typical for a starter template. It says nothing about the licences of the Angular, Electron or other dependencies you add, and nothing in the repository reviews those for you. If you ship a commercial desktop app, the dependency audit is your responsibility, not the template's. This is not legal advice; check the terms that apply to your distribution.

Editorial conclusion

Adopt it if you want an Angular desktop shell where the main process, renderer and packaging config already exist and you are willing to respect the two-package.json dependency rule. Do not adopt it if you need hot reload in the Electron main process, since the README states the main process can only be restarted, or if you want a single dependency manifest. Before committing, verify that the Node version in .node-version matches your CI, that your Node-only libraries are declared in both app/package.json and the root package.json, and that npm run electron:build produces the artifacts your target OS needs.

Frequently asked questions

Official sources

1. belnadris/angular-electron on GitHub
2. License: MIT
3. Project website
4. README
5. Releases