Aurelia CLI with electron

This morphed into a much better Electron starter template than I could have hoped for.

1 Like

I have a working base setup with TypeScript, Tslint, jest, Scss and stylelint, both for Front/Backend (renderer/main) separated and all tasks configured. Its based on RequireJS though but I guess it should be easy to switch out. I’ll create the repo tomorrow if you’re interested.


YES PLEASE!!! I need to get moving on an actual application like last week :slight_smile:


I was just going to use @timfish webpack repo, but it won’t load css from modules so that makes working with some external plugins problematic.

1 Like

Alright I’ve created the repository over here

Depending on your preference/use case you’ll might have to modify certain parts such as the stylelint rules, which are optimized for SCSS + BEM, or the TSLint ruleset. Also, if you intend to pack the app, you might want to shift around output folders for the renderer process, which is described in section Structure.


Awesome, i’ll check it out later. It’s been a while since I used requirejs. Do you still need to add all the dependencies to the bundles in aurelia.json?

I ultimately don’t care which bundler I use as long as there are no limitations.

1 Like

nope, no need to touch the aurelia.json for the most part since the new CLI, same as for SystemJS does the handling by itself.

See for details


I’m experimenting with it right now. It seems to run fine doing the npm start but when I do npm electron or attempt to package it with electron-packager I’m getting an error window. Do you have any thoughts. I really appreciate what you have done already

A javascript error occured in the main process
Uncaught exception:
Error: connect ECONREFUSED at TCPConnectWrap.afterConnect [as oncomplete](net.js:1161:14)
1 Like

Hey there,

yep the issue was that the electron-connect - the tool that will auto-restart (like browserSync) your electron app both on backend/frontend changes - isn’t started in the case of npm run electron, as the start happens within the run task. I’ve added now a env var to check for so now it should work properly.

With regards to electron-packager, I guess that was the same issue. Since the process of creating a packaged app is very specific to your project I didn’t add an example, since I’m personally preferring electron-build due to the included updater and binary build targets for all 3 major platforms including NSIS support.
Anyways, what I’d typically use to strip out code that shouldn’t land in the resulting build is gulp-preprocess. I’ve now also wrapped that electron-connect client part in a !=prod section as a demo.

1 Like

I’ve also updated the sample to use the latest version of Electron since it was locked into v3, plus added some descriptions on how you can use Electrons require in the renderer process. While you shouldn’t use nodeIntegration if you can avoid it, the sample is still showing it so in the case you have to it’s already properly setup

EDIT: also added a sample on how to handle native OS theme preferences in CSS, due to proper support in v7


This is awesome. This should be the aurelia way.

So regarding a packaged build. Did you mean electron-builder? My requirement to build the executable (installer or zip of files) requires me to be able to build on an offline network. I haven’t really touched this end to much yet, but to fully flesh out a plan I’m just trying to get these basics working. Getting things working in my environment is not easy sometimes.

1 Like

oh wow, that escalated quickly :slight_smile:

Yeah I meant electron-builder, sorry for the typo. That one should allow you to define whatever output you want per OS, be it zip, binary or OS specific packages such as AppImage on Linux. Sure your situation is quite an uncommon scenario to build in isolation. So there are a few things you need to keep in mind when doing so:

  • You need to get the initial set of dependencies. Either you connect once to get them and cache or you use an internal dependency management system like Artifactory or whatever else. As for caching see these instructions to build from cache
  • Codesigning might bite you in an offline mode. More specifically the communication with the timeserver. Now that said it depends on how you want to achieve this, since you could technically host that by yourself OR do the code-signing in a phase two from a remote capabale of connecting to the internet OR adding the timeserver to your DMZ. Again this really heavily depends on your infrastructure/use case but there are ways to solve that.

Updated the repo to include E2E tests with Spectron, since this is quite often a nightmare to get right together with Typescript and all the proper typings for the various versions of Spectron/WebdriverIO.


Leaving this here for history, but just using scss in the app is the way to go, there are no negatives as far as I can see. I used to think scss compile was slow though.

The only issue I ran into so far is I tried to require another css file into the app.html and that is failing

I’m just doing this. the material kit css is copied local so I can remove the font import since I’ll be offline. It appears that actual css files cannot be loaded this way. anyway to allow both css and scss from the app? If i use the scss version it’s okay. As long as I have control of the file, i don’t have a problem just changing the extension. Loading css from a node_module is no problem

  <require from="./styles/material-kit/assets/css/material-kit.css"></require>
  <require from="./app.css"></require>
1 Like

Would you mind sharing electron-builder basic config. I keep getting an error “Not allowed to load local resource”

Solved that with this config

"build": {
    "appId": "Aurelia",
    "files": [
1 Like

I’ll try to get into that tomorrow


this is great!!

How does one access the aurelia_project/environments files from the backend?

1 Like

hey there, I’ve updated the sample to include electron-builder configured for Mac builds.

EDIT: now including a multi-target build and configuration for Linux/Windows. Note though, that I haven’t checked the later two since I’m currently running on Mac.


Ehm, dunno I haven’t used those as generally I try to stick to NODE_ENV vars. but what prohibits you from simply importing it?

EDIT: If you need to change the place where the file is generated, so e.g you can access it both in renderer and main from a common shared place, just adapt this transpile task. Also make sure to tweak both tsconfig/_backend.json to include the new destination.

1 Like

Thank you. I’m glad I did something right with the build! I don’t use macs and don’t have access to one so that one is out, but I trust that it is correct.

1 Like