{"id":488,"date":"2017-04-10T10:04:00","date_gmt":"2017-04-10T10:04:00","guid":{"rendered":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?p=488"},"modified":"2020-06-09T13:46:11","modified_gmt":"2020-06-09T13:46:11","slug":"building-cross-platform-desktop-apps-with-angular-and-electron","status":"publish","type":"post","link":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/","title":{"rendered":"Building Cross Platform Desktop Apps with Angular and Electron"},"content":{"rendered":"\n
\n
\n
\"\"<\/figure>\n<\/div>\n\n\n\n
\n

The rapid development in the world of web technologies, especially in SPA frameworks like Angular<\/a> and React<\/a>, empowers developers to build enterprise scale, platform independent applications with a flexible and vivid technology stack. Although these applications can fulfill numerous use cases they may fall short in others because of the limitations web applications have. Especially the limited environment integration and system access capabilities make some kinds of applications impossible (e.g. missing file system access) or hurt the user experience (e.g. no offline usage, no integration into application menu or task bar in most cases).<\/p>\n<\/div>\n<\/div>\n\n\n\n

The Electron Framework<\/a> by GitHub<\/a> attempts to tackle those problems while preserving the advantages of web technologies by wrapping conventional web apps as native applications and giving them powerful access to the underlying system and their environment.<\/p>\n\n\n\n

In this article we will go over the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.<\/p>\n\n\n\n

<\/div>\n\n\n\n

About Electron<\/h2>\n\n\n\n

Electron is an open source framework developed by GitHub for the Atom project<\/a>. It integrates web technology based applications into the system, to make them work like native applications. To do so, it uses the rendering component of the Chromium browser<\/a> to render the web views, while executing the JavaScript elements of the app in the Node.js<\/a> runtime environment to provide access to the underlying system. In addition Electron brings additional APIs to integrate the application into the environment (e.g. with keyboard listeners, notifications, tray integration, etc.) it runs in.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Creating an Electron application<\/h3>\n\n\n\n

To run a web app in Electron, you need to provide an entry point script to the electron binary (which is available as binary package or as NPM module). You can find an example of an entry point script at the Electron quick start repo<\/a>. The entry point (which is run in the Main Process<\/strong><\/a>) can register global handlers for the app (e.g. keyboard shortcuts, behavior on closing, etc.) and creates one or multiple windows for the app via<\/p>\n\n\n\n

    const {app, BrowserWindow} = require('electron')\n    const path = require('path')\n    const url = require('url')\n    \/\/ Create the browser window.\n    win = new BrowserWindow({width: 800, height: 600})\n    \/\/ and load the index.html of the app.\n    win.loadURL(url.format({\n      pathname: path.join(__dirname, 'index.html'),\n      protocol: 'file:',\n      slashes: true\n    }))<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Each of the windows runs the specified web page (index.html<\/code> in this example) and the associated JavaScript in a Render Process<\/strong><\/a>. All the JavaScript in this Render Process has access to the full Node.js API<\/a> and all available NPM packages<\/a>, to the DOM, which is visually represented by the Chromium renderer of this process, as well as to parts of the Electron API<\/a>.<\/p>\n\n\n\n
You can pass an entry point script to Electron either via the command line arguments of the Electron binary (e.g. electron .\/index.js<\/code>) or you pass a directory containing an package.jsonto the Electron command (e.g. electron .\/project\/). In the latter case electron executes the file referenced by the mainfield of the package.json.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Building desktop apps with Angular<\/h2>\n\n\n\n
Because Electron doesn\u2019t constrain the used web technology stack, it\u2019s possible to use Angular to create an Electron Desktop App. To spin up your project, you can use this project seed<\/a> and all configuration changes, which we will perform during this article are available in this Gist<\/a>.<\/p>\n\n\n\n
For the purpose of this article we will build a Hello World app with Angular and Electron to demonstrate the setup of such a project. You can find the resulting application in this GitHub repository<\/a>. The commit which corresponds to the upcomming changes will be linked on top of every section.<\/p>\n\n\n\n
We will use the Angular-CLI<\/a> which is a tool for generating Angular Projects without having to bother with the configuration and selection of all necessary and fast evolving tools and best practices in the Web ecosystem. In addition to the setup off linting<\/a>, building<\/a>, bundling<\/a> and testing<\/a> tools it brings some neat little features like code scaffolding<\/a> or a development server<\/a>.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Setting up the project<\/h3>\n\n\n\n
Commit: f661853<\/a><\/p>\n\n\n\n
In this project we will use Yarn<\/a> as an alternative to npm<\/a> for installing and managing our dependencies. If you have not made the transition to Yarn yet you can use this guide<\/a> for the migration. If you do not want to switch that\u2019s no problem either, you just have to use the equivalent npm commands<\/a>.<\/p>\n\n\n\n
Let\u2019s start by setting up a new mostly configured project with the new<\/code> command of the Angular-CLI. So install the Angular-CLI on your system with<\/p>\n\n\n\n
yarn global add @angular\/cli<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Although the Angular-CLI already switched to Yarn internally, it still sets up your projects via npm. If you do not want this you can configure the CLI to use Yarn by running<\/p>\n\n\n\n
ng set --global packageManager=yarn<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Then you can run<\/p>\n\n\n\n
ng new hello-electron<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
This creates a new Angular Project named hello-electron<\/em>, which is already preconfigured as a web project. The installation of the project dependencies causes the yarn.lock<\/code> file, which pins your projects dependencies<\/a>. Commit this file to keep track of your dependencies correctly. To test if there were any issues while setting up the base project, you can run the default application. To do so, run ng serve<\/code> and head your browser to the location which is printed in the terminal (normally this is http:\/\/localhost:4200). You should see the Text \u201cApp works!<\/em>\u201c<\/p>\n\n\n\n
\"Screenshot:
Figure 1: Angular-CLI default app<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n
Because the Angular-CLI isn\u2019t aware of the possibility of building Electron Desktop Apps (yet) neither the build will work out of the box nor the build results will run in Electron. To achieve this, we need to reconfigure some parts of the setup.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Ejecting the project<\/h3>\n\n\n\n
Commit: 48da720<\/a><\/p>\n\n\n\n
Angular-CLI brings a lot of tools for managing, building and supporting our project. The configuration and invocation of these tools is managed internally and automatically by the CLI and is accessed via the corresponding CLI commands. While this is very convenient it limits our influence on the build and tooling, especially if we want to achieve more exotic effects, which are out of the scope of the Angular-CLI. Because we want to make a lot of changes to the projects configuration during this article, we have to \u201ceject\u201d the project from the Angular-CLI. This means that all build and tool configuration files get generated and added to our project. After this some of the CLI commands (like build or serve) no longer work and get substituted by mostly equivalent Yarn \/ NPM scripts.<\/p>\n\n\n\n
To eject the Project run<\/p>\n\n\n\n
ng eject<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
and install some new and some missing dependencies via<\/p>\n\n\n\n
    yarn install\n    yarn add --dev webpack html-webpack-plugin extract-text-webpack-plugin postcss-url @ngtools\/webpack<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Installing Electron<\/h3>\n\n\n\n
Commit: 54800ba<\/a><\/p>\n\n\n\n
To use electron (and the corresponding TypeScript typings), we install it locally into our project for development purposes to set a working version and list it in our dev-dependencies:<\/p>\n\n\n\n
yarn add --dev electron @types\/electron<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Adapting entry point web page<\/h3>\n\n\n\n
Commit: a16854d<\/a><\/p>\n\n\n\n
The file src\/index.html<\/code> is the entry point for our Angular application. We need to adapt the base<\/code> tag from<\/p>\n\n\n\n
    <!doctype html>\n    <html>\n      <head>\n        [...]\n        <base href=\"\/\">\n        [...]\n      <\/head>\n      [...]\n    <\/html><\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
to<\/p>\n\n\n\n
    <!doctype html>\n    <html>\n      <head>\n        [...]\n        <base href=\".\/\">\n        [...]\n      <\/head>\n      [...]\n    <\/html><\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
because Electron doesn\u2019t resolve included files relatively to the current domain (like web browsers do), but relatively to the current file tree, so the base<\/code> \/<\/code> would resolve relatively to the file system root. We want the dependencies to get resolved relatively to the location of index.html<\/code>, so we use .\/<\/code>.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Setting the correct polyfills<\/h3>\n\n\n\n
Commit: dff6c21<\/a><\/p>\n\n\n\n
The file src\/polyfills.ts<\/code> includes some polyfills<\/a> into the project. The Polyfill zone.js<\/a>, which is necessary to detect asynchronous code execution to trigger the Angular change detection correctly<\/a> by implementing a concept named \u201cZones\u201d<\/a> doesn\u2019t work by default with Node.js, which is used for some parts of the Code execution in Electron. To make the change detection work with Node.js, a different version of the zone.js polyfill called zone-node<\/code> exists. To enable the correct change detection for Node.js as well for ordinary Angular Code we have to include the zone-mix<\/code> polyfill. To do so, we have to change the line<\/p>\n\n\n\n
    [...]\n    import 'zone.js\/dist\/zone';\n    [...]<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
to<\/p>\n\n\n\n
    [...]\n    import 'zone.js\/dist\/zone-mix';\n    [...]<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
in src\/polyfills.ts<\/code>.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Adapting the Webpack configuration<\/h3>\n\n\n\n
Commit: ae3cc50<\/a><\/p>\n\n\n\n
The Angular-CLI uses Webpack<\/a> to handle the project build, the development server and particularly the module bundling. (Theoretically we don\u2019t need module bundling when using Electron, because Node.js has native support for modules, but because Webpack handles so much different things of our projects infrastructure, it is easier to configure Webpack for Electron and bundle our project, than it is to rebuild all the infrastructure ourselves.)<\/p>\n\n\n\n
To set up Webpack for our build open the webpack.config.js<\/code> file and modify the returned Object in the following way:<\/p>\n\n\n\n
    [...]\n    module.exports = {\n      \/\/ inserted line\n      \"target\": \"electron-renderer\",\n      [...]\n      \/\/ modified entry\n      \"node\": {\n        \"fs\": false,\n        \"global\": false,\n        \"crypto\": false,\n        \"tls\": false,\n        \"net\": false,\n        \"process\": false,\n        \"module\": false,\n        \"clearImmediate\": false,\n        \"setImmediate\": false,\n        \"Buffer\": false,\n        \"__filename\": false,\n        \"__dirname\": false\n      }\n    };<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
This configures Webpack not to build for a Web environment but for an Electron rendering Process and to leave all references to Node core modules untouched. Basically this allows you to include Node.js core modules as well as using browser and Electron specific APIs (like the DOM) in your application (read more about different targets in the Webpack documentation<\/a>).<\/p>\n\n\n\n
We also want our Electron entry point script (which we will add to the project shortly) to be automatically copied from our project sources to our build result.
We can achieve this with Webpack by installing the copy-webpack-plugin<\/code><\/a> into our project viayarn add --dev copy-webpack-plugin<\/code><\/p>\n\n\n\n
Now we can use it by including it in our webpack.config.js<\/code>:<\/p>\n\n\n\n
    const CopyWebpackPlugin = require('copy-webpack-plugin');\n    [...]\n    module.exports = {\n      [...]\n      plugins: [\n        [...]\n        \/\/ inserted lines\n        new CopyWebpackPlugin([{\n          context: path.resolve(__dirname, \"src\"),\n          from: \"entry.js\"\n        }]),\n        [...]\n      ],\n      [...]\n    }<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
This copies the file entry.js<\/code> from our source folder to the root of our build result.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Fixing the TypeScript configuration<\/h3>\n\n\n\n
Commit: a775a79<\/a><\/p>\n\n\n\n
Because of a bug in the TypeScript loader used by the build the type root isn\u2019t resolved correctly by default. To fix this set the type roots explicitly in the TypeScript configuration files src\/tsconfig.app.json<\/code>, src\/tsconfig.app.json<\/code> and e2e\/tsconfig.e2e.json<\/code> and add the entry \"node\"<\/code> to the types<\/code> array:<\/p>\n\n\n\n
    {\n      \"compilerOptions\": {\n        [...]\n        \"typeRoots\": [\n            \"..\/node_modules\/@types\"\n        ],\n        types: [\n          \"node\",\n          [...]\n        ],\n        [...]\n      },\n      [...]\n    }<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Adapting unit test configuration<\/h3>\n\n\n\n
Commit: 9c4c3e4<\/a><\/p>\n\n\n\n
Easy and integrated unit testing is another major feature of the Angular-CLI, which does not run out of the box, when using Electron as environment. All tests, which involve features of the Node.js environment fail, because they are not available in the normal Browser, which the preconfigured test runner uses to run the tests in. To run our unit test, we have to configure the test runner, to run our tests in Electron, too.
To do so, install the Electron launcher<\/a> for the Karma test runner<\/a> via<\/p>\n\n\n\n
yarn add --dev karma-electron<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Then open the file karma.conf.js<\/code> and perform the following modifications:<\/p>\n\n\n\n
    [...]\n    module.exports = function (config) {\n      config.set({\n        [...]\n        plugins: [\n          require('karma-jasmine'),\n          \/\/ modified line, previously: require('karma-chrome-launcher')\n          require('karma-electron'),\n          [...]\n        ],\n        [...]\n        client: {\n          \/\/ inserted line\n          useIframe: false,\n          [...]\n        },\n        [...]\n        \/\/ modified line\n        browsers: ['Electron'],\n        [...]\n      });\n    };<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
This configures Karma to use Electron and execute every test in a new Browser (Electron) window, instead of in an iFrame<\/code> in the same window. This is necessary, because iFrames<\/code> in Electron have no access to the Node.js environment, while windows have.<\/p>\n\n\n\n
With these changes we have set up the provided unit testing for our Angular-Electron app and can run the test via yarn run test<\/code>.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Configure End-To-End testing<\/h3>\n\n\n\n
Commit: cf0451a<\/a><\/p>\n\n\n\n
The Angular-CLI also brings a setup for End-To-End (aka. e2e, aka. UI-Testing) which can easily be configured to use Electron as execution environment instead of Google Chrome because it can provide the same webdriver interface as Chrome. To configure the e2e testing framework (called Protractor<\/a>) open the file protractor.conf.js<\/code> and adapt it the following way:<\/p>\n\n\n\n
    [...]\n    exports.config = {\n      [...]\n      capabilities: {\n        \/\/ inserted lines\n        chromeOptions: {\n          binary: '.\/node_modules\/electron\/dist\/electron',\n          args: ['--test-type=webdriver']\n        },\n        'browserName': 'chrome'\n      },\n      [...]\n    };<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Now Protractor uses Electron instead of Chrome and all your tests will work, even when they use Node.js features. Be aware, that the End-To-End testing setup of the Angular-CLI requires a running dev server, which we will configure in the next section.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Adapting the package configuration<\/h3>\n\n\n\n
Commit: e426edd<\/a><\/p>\n\n\n\n
To optimize our workflow I highly recommend setting some properties and scripts in our projects package.json<\/code>.<\/p>\n\n\n\n
To make Electron behave correctly, when initialized in the projects root directory, set the main<\/code> field of the package.json<\/code>:<\/p>\n\n\n\n
    {\n      [...]\n      \"main\": \"dist\/entry.js\",\n      [...]\n    }<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
dist\/entry.js<\/code> will be the location of our Electron entrypoint in the build result.<\/p>\n\n\n\n
To run our app, we add the run<\/code> script, which invokes Electron in our package directory:<\/p>\n\n\n\n
    \"run\": \"electron .\",<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
So running yarn run run<\/code> will launch our Electron app.<\/p>\n\n\n\n
Now we have a project setup, which will allow us to build, test and run our app, but the Angular-CLI provides another very neat feature called LiveReload. LiveReload spins up a webserver via the Webpack dev server, which serves our app wrapped in some more JavaScript, that reloads our app automatically from the server when it changes, while our sources get recompiled every time they are modified. This makes it possible to develop our app while constantly seeing the current state and without having to compile and run it by hand every time we make a change. Because we use Electron instead of a browser and we want to build desktop apps, we load our app directly from the build result and have no connection to the LiveReload server by default. To use this feature, we have to crate a second, slightly modified Electron entry point for development purposes and load this one to use LiveReload. We now create an additional NPM script, which concurrently starts the dev server and our Electron binary with our \u201clive\u201d entry point (which we will create later). To do so, we use the tool concurrently<\/code><\/a>, which we install with<\/p>\n\n\n\n
yarn add --dev concurrently<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Then we modify the following script in our package.json<\/code>:<\/p>\n\n\n\n
    \"start\": \"concurrently \\\"webpack-dev-server --port=4200\\\" \\\"electron src\/entry.live.js\\\"\",<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Creating the entry points<\/h3>\n\n\n\n
Commit: c5ccedf<\/a><\/p>\n\n\n\n
To load our App into Electron, we need to create an entry point at src\/entry.js<\/code>, whose main purpose is to load the entry point HTML document (which is generated in the build process). We use this<\/a> slightly modified version of the example entry point from the Electron documentation. Basically the entry point loads the file index.html<\/code> in the same directory as the entry point itself into a new window by calling<\/p>\n\n\n\n
    win.loadURL(url.format({\n      pathname: path.join(__dirname, 'index.html'),\n      protocol: 'file:',\n      slashes: true\n    }))<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
It also handles general application lifecycle events like application start or exit and registers environment integration like keyboard bindings or tray icons.
A small modification opens the developer tools, when the app is started with the environment variable NODE_ENV=development<\/code> set.<\/p>\n\n\n\n
To make use of LiveReloading, we also need the alternative entry point src\/entry.live.js<\/code> which you can find here<\/a>. This entry point is mostly the same as src\/entry.js<\/code>. The only difference is, that the application entry point page gets loaded from the dev server instead of the file system. By default the dev server serves at http:\/\/localhost:4200<\/code>, so we change the lines<\/p>\n\n\n\n
    [...]\n    function createWindow () {\n      [...]\n      win.loadURL(url.format({\n        pathname: path.join(__dirname, 'index.html'),\n        protocol: 'file:',\n        slashes: true\n      }))\n      [...]\n    }\n    [...]<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
to<\/p>\n\n\n\n
    [...]\n    function createWindow () {\n      [...]\n      win.loadURL(url.format({\n        pathname: 'localhost:4200',\n        protocol: 'http:',\n        slashes: true\n      }))\n      [...]\n    }\n    [...]<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
We also want to set a short timeout, so we reduce the chance of loading the file from the server, before the server has finished building (you may adapt the time according to your project size and the resulting build time). To do so, we change the createWindow<\/code> function:<\/p>\n\n\n\n
    [...]\n    function createWindow () {\n      \/\/ content\n      [...]\n    }\n    [...]<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
to<\/p>\n\n\n\n
    [...]\n    function createWindow () {\n      setTimeout(() => {\n        \/\/ content\n        [...]\n      }, 12000)\n    }\n    [...]<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
Because the dev server only serves the static files and handles the changes, it is not relevant, if the code inside the application bundle is written for the browser or for Electron and Electron executes any provided code in the bundle, whether it is generated by your sources or by the dev server. So the page gets loaded and reloads itself, when the dev server recognizes changes.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Adding Devtron<\/h3>\n\n\n\n
Commit: 0832c1b<\/a><\/p>\n\n\n\n
Devtron<\/a> is an extension for the Electron DevTools, which helps you developing your app by giving you more information about Electron internals, like the Inter-Process-Communication (IPC) mechanism or the established event listeners. Just install it to the project via<\/p>\n\n\n\n
yarn add --dev devtron<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
and install it to the DevTools right after opening them, when the app is started in development mode, by modifying the following section in entry.js<\/code> and entry.live.js<\/code>:<\/p>\n\n\n\n
    [...]\n    function createWindow () {\n      [...]\n      \/\/ Open the DevTools when in dev mode.\n      if(process.env.NODE_ENV=='development') {\n        win.webContents.openDevTools()\n        require('devtron').install()\n      }\n      [...]\n    }\n    [...]<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
When launching your app with NODE_ENV=development<\/code> set, you will now find a Devtron tab in the DevTools, which shows you the intended information.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Application bundling<\/h3>\n\n\n\n
Commit: d0b7f30<\/a><\/p>\n\n\n\n
After building our application inside our development environment, we want to distribute our app as platform specific packages. Package distribution in the Electron world usually works by packing all the necessary application resources together with the Electron binary for the specific target platform. The binary is renamed to the name of your application, so when running the resulting executable, Electron is started, locates your entry point (because it is noted in the package.json<\/code>) and loads your application.
Conveniently there is a tool called electron-packager<\/a>, which automates the process of packaging your application for different platforms and architectures and carries the responsibility for creating all the platform specific packaging formats, configuration files, icon formats, etc.
So let us install the tool<\/p>\n\n\n\n
yarn add --dev electron-packager<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
and include it into our workflow by adding the following scripts to our package.json<\/code>:<\/p>\n\n\n\n
    \"package:linux\": \"electron-packager . $npm_package_name-$npm_package_version --ignore=src --ignore=node_modules --ignore=e2e --ignore=.*\\\\.conf\\\\.js --ignore=\\\"(angular-cli|tsconfig)\\\\.json\\\" --ignore=webpack.*\\\\.js --out=packages --platform=linux --arch=all --overwrite\",\n    \"package:mac\": \"electron-packager . $npm_package_name-$npm_package_version --ignore=src --ignore=node_modules --ignore=e2e --ignore=.*\\\\.conf\\\\.js --ignore=\\\"(angular-cli|tsconfig)\\\\.json\\\" --ignore=webpack.*\\\\.js --out=packages --platform=darwin --arch=all --overwrite \",\n    \"package:win\": \"electron-packager . $npm_package_name-$npm_package_version --ignore=src --ignore=node_modules --ignore=e2e --ignore=.*\\\\.conf\\\\.js --ignore=\\\"(angular-cli|tsconfig)\\\\.json\\\" --ignore=webpack.*\\\\.js --out=packages --platform=win32 --arch=all --overwrite \",\n    \"package:all\": \"electron-packager . $npm_package_name-$npm_package_version --ignore=src --ignore=node_modules --ignore=e2e --ignore=.*\\\\.conf\\\\.js --ignore=\\\"(angular-cli|tsconfig)\\\\.json\\\" --ignore=webpack.*\\\\.js --out=packages --all --overwrite\"<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
These scripts create the application packages for the specified platforms in the directory packages<\/code> and the --ignore<\/code> flags prevents the inclusion of files, which are unnecessary for the package (some directories like your devDependencies<\/code> or .git<\/code> are ignored by default). Because Webpack already bundles our dependencies into the JavaScript bundles inside the dist<\/code> folder, we don\u2019t even need to include the dependencies in node_modules<\/code>. You can also build your packages on your CI system to automate your application distribution, but it has to be said, that packaging for Windows on non-Windows systems requires Wine, which on the other hand may not deal very well with headless systems out of the box. You may also add the packages<\/code> folder to your .gitignore<\/code> file.<\/p>\n\n\n\n
Now we have a completely configured project environment, for building an Angular-Electron App, with all the features, which are available through the Angular-CLI. We can now go on with creating our little app itself.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Building our app<\/h3>\n\n\n\n
Commit: 888a4d2<\/a><\/p>\n\n\n\n
To make our app say hello we need to set the value of the title<\/code> property in the AppComponent<\/code> class in src\/app\/app.component.ts<\/code> to our desired value, let\u2019s say \u2018Hello Electron!\u2019<\/p>\n\n\n\n
    [...]\n    export class AppComponent {\n      title = 'Hello Electron!';\n    }<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
To make our tests pass, we need to set this text in the components test src\/app\/app.component.spec.ts<\/code> as well es in the e2e test specification e2e\/app.e2e-spec.ts<\/code>.<\/p>\n\n\n\n
After this we can build and run our app with<\/p>\n\n\n\n
yarn run build && yarn run run<\/code><\/pre>\n\n\n\n
<\/div>\n\n\n\n
\"Screenshot
Figure 2: Hello Electron app<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n
With this setup you can build powerful desktop applications, while being supported by the rapidly evolving ecosystem of Node.js, Angular and the Angular-CLI.<\/p>\n\n\n\n
In the next article<\/a> we will build a simple file explorer with these technologies to gain a deeper insight into the power of Node.js and the Electron API.<\/p>\n","protected":false},"excerpt":{"rendered":"
In this blog post we introduce the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.<\/p>\n","protected":false},"author":68,"featured_media":619,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","footnotes":""},"categories":[8],"tags":[261,263,271,300],"topics":[],"class_list":["post-488","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web","tag-angular","tag-electron","tag-cross-platform","tag-cross-platform-desktop-apps"],"acf":[],"yoast_head":"\nBuilding Cross Platform Desktop Apps ... - ZEISS Digital Innovation Blog<\/title>\n<meta name=\"description\" content=\"In this blog post we introduce the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Building Cross Platform Desktop Apps ... - ZEISS Digital Innovation Blog\" \/>\n<meta property=\"og:description\" content=\"In this blog post we introduce the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/\" \/>\n<meta property=\"og:site_name\" content=\"Digital Innovation Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-04-10T10:04:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-06-09T13:46:11+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1281\" \/>\n\t<meta property=\"og:image:height\" content=\"734\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Leo Lindhorst\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Leo Lindhorst\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"17 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/\",\"name\":\"Building Cross Platform Desktop Apps ... - ZEISS Digital Innovation Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png\",\"datePublished\":\"2017-04-10T10:04:00+00:00\",\"dateModified\":\"2020-06-09T13:46:11+00:00\",\"author\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/c356f48797f27ea4dae06817bc32afae\"},\"description\":\"In this blog post we introduce the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.\",\"breadcrumb\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#primaryimage\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png\",\"contentUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png\",\"width\":1281,\"height\":734},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Building Cross Platform Desktop Apps with Angular and Electron\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/\",\"name\":\"Digital Innovation Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/c356f48797f27ea4dae06817bc32afae\",\"name\":\"Leo Lindhorst\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2024\/06\/Lindhorst_Leo_Profilbild_300x300px-150x150.jpg\",\"contentUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2024\/06\/Lindhorst_Leo_Profilbild_300x300px-150x150.jpg\",\"caption\":\"Leo Lindhorst\"},\"description\":\"Leo Lindhorst is a Management Consultant with ZEISS Digital Innovation. He is working together with his clients in the healthcare, medical technology and pharmaceuticals industries, to define the vision for their digital product landscape, consults them on the best technological and organizational solution for their ambitions and supports them in setting up and leading their software development program.Together with the teams of ZEISS Digital Innovation, Leo is ensuring the delivery of the client\u2019s innovative digital health solutions from design, over implementation to successful operations in the field.\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/author\/enleolindhorst\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Building Cross Platform Desktop Apps ... - ZEISS Digital Innovation Blog","description":"In this blog post we introduce the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/","og_locale":"en_US","og_type":"article","og_title":"Building Cross Platform Desktop Apps ... - ZEISS Digital Innovation Blog","og_description":"In this blog post we introduce the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.","og_url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/","og_site_name":"Digital Innovation Blog","article_published_time":"2017-04-10T10:04:00+00:00","article_modified_time":"2020-06-09T13:46:11+00:00","og_image":[{"width":1281,"height":734,"url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png","type":"image\/png"}],"author":"Leo Lindhorst","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Leo Lindhorst","Est. reading time":"17 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/","name":"Building Cross Platform Desktop Apps ... - ZEISS Digital Innovation Blog","isPartOf":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#primaryimage"},"image":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#primaryimage"},"thumbnailUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png","datePublished":"2017-04-10T10:04:00+00:00","dateModified":"2020-06-09T13:46:11+00:00","author":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/c356f48797f27ea4dae06817bc32afae"},"description":"In this blog post we introduce the process of building a hybrid Desktop App with Angular using the Angular-CLI and Electron.","breadcrumb":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#primaryimage","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png","contentUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi.png","width":1281,"height":734},{"@type":"BreadcrumbList","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/building-cross-platform-desktop-apps-with-angular-and-electron\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/"},{"@type":"ListItem","position":2,"name":"Building Cross Platform Desktop Apps with Angular and Electron"}]},{"@type":"WebSite","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/","name":"Digital Innovation Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/c356f48797f27ea4dae06817bc32afae","name":"Leo Lindhorst","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/image\/","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2024\/06\/Lindhorst_Leo_Profilbild_300x300px-150x150.jpg","contentUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2024\/06\/Lindhorst_Leo_Profilbild_300x300px-150x150.jpg","caption":"Leo Lindhorst"},"description":"Leo Lindhorst is a Management Consultant with ZEISS Digital Innovation. He is working together with his clients in the healthcare, medical technology and pharmaceuticals industries, to define the vision for their digital product landscape, consults them on the best technological and organizational solution for their ambitions and supports them in setting up and leading their software development program.Together with the teams of ZEISS Digital Innovation, Leo is ensuring the delivery of the client\u2019s innovative digital health solutions from design, over implementation to successful operations in the field.","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/author\/enleolindhorst\/"}]}},"author_meta":{"display_name":"Leo Lindhorst","author_link":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/author\/enleolindhorst\/"},"featured_img":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2017\/04\/201704_desktop_apps_angular_electron_fi-600x344.png","coauthors":[],"tax_additional":{"categories":{"linked":["<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/web\/\" class=\"advgb-post-tax-term\">Web<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">Web<\/span>"]},"tags":{"linked":["<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/web\/\" class=\"advgb-post-tax-term\">Angular<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/web\/\" class=\"advgb-post-tax-term\">Electron<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/web\/\" class=\"advgb-post-tax-term\">Cross platform<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/web\/\" class=\"advgb-post-tax-term\">Cross Platform Desktop Apps<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">Angular<\/span>","<span class=\"advgb-post-tax-term\">Electron<\/span>","<span class=\"advgb-post-tax-term\">Cross platform<\/span>","<span class=\"advgb-post-tax-term\">Cross Platform Desktop Apps<\/span>"]}},"comment_count":"0","relative_dates":{"created":"Posted 9 years ago","modified":"Updated 6 years ago"},"absolute_dates":{"created":"Posted on April 10, 2017","modified":"Updated on June 9, 2020"},"absolute_dates_time":{"created":"Posted on April 10, 2017 10:04 am","modified":"Updated on June 9, 2020 1:46 pm"},"featured_img_caption":"","series_order":"","_links":{"self":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts\/488","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/comments?post=488"}],"version-history":[{"count":6,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts\/488\/revisions"}],"predecessor-version":[{"id":618,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts\/488\/revisions\/618"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/media\/619"}],"wp:attachment":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/media?parent=488"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/categories?post=488"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/tags?post=488"},{"taxonomy":"topics","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/topics?post=488"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}