Electron is a framework for building cross-platform desktop applications using Web front-end technology. It integrates Chromium and Node.js event loops together and provides some apis for interacting with native systems. In short, Electron makes it easy to build a desktop-level application that runs on Windows, Linux, and Mac using familiar front-end technology. There have been many articles about how to develop full-platform applications, but less about how to efficiently and easily build software packages and distribute them to the public. This article describes a simple and efficient way to build and distribute an installation package.

AlphaT is an app I recently developed using Electron. Some of the lessons learned in building and launching the app led to this blog post.

A brief description of the build and release process: Configure the build tool electron builder, configure Travis to build Linux and Mac applications, and configure AppVeyor to build Windows applications. When submitting code to Github, CI automatically pulls the code. Run the auto-Builder command to generate the installation package for each platform, and then push the installation package to Github Releases.

It must be complicated to do something so cool that you can automatically build and publish with just git commit.

It’s not really complicated, it’s just simple configuration. By the way, Travis and AppVeyor are free to use for open source projects. I’ll explain it step by step.

Use the electron – builder

The electron Builder is an electron application packaging tool, which can be easily configured to generate installation packages of different platforms and formats. Supported packages include mas, DMG, and PKG for the MAC platform. Win platform nsis, nsisWeb, portable, appx, squirrelWindows; Deb, Snap, appImage, Pacman, RPM, FreeBSD, P5P, APK for Linux. It also supports uploading built packages to services such as Github Releases, Amazon S3, and so on. From build to release, the only thing left to do is configure correctly.

  • The installation
npm install electron-builder --save-dev
Copy the code
  • Add a script
"postinstall": "electron-builder install-app-deps",
"dist": "electron-builder --publish onTagOrDraft"
Copy the code

Postinstall is not required, only if native modules are used.

Publish onTagOrDraft Is used for automatic publishing. For details, see the documentation

  • Build configuration

Electron can read configuration information from the package.json build

"build": {
  "appId": "com.sigoden.alphat",
  "mac": {
    "category": "public.app-category.utilities"
  },
  "dmg": {
    "contents": [
      {
        "x": 110,
        "y": 150
      },
      {
        "x": 240,
        "y": 150,
        "type": "link",
        "path": "/Applications"
      }
    ]
  },
  "win": {
    "target": "nsis"
  },
  "linux": {
    "category": "Utility",
    "target": [
      "deb",
      "AppImage"
    ]
  }
}
Copy the code

MAC and DMG will guide the electron Builder for building applications for Apple systems, win for building Windows applications, it says make the installation package in NSIS format, Linux for building Linux applications, It will generate the installation package deb and appImage.

For MAC and Linux categories, see MAC category and Linux Category for optional fields

  • Provide the icon

Icon is required, missing and sizing errors will cause a build failure.

Build ├ ─ ─ icon. Icns ├ ─ ─ icon. Ico └ ─ ─ the ICONS ├ ─ ─ 1024 x1024. PNG ├ ─ ─ 128 x128. PNG ├ ─ ─. 16 x16 PNG ├ ─ ─ 24 x24. PNG ├ ─ ─ 256 x256. PNG ├ ─ ─ 32 x32. PNG ├ ─ ─ 48 x48. PNG ├ ─ ─ 512 x512. PNG ├ ─ ─ 64 x64. PNG └ ─ ─ 96 x96. PNGCopy the code

I’ve provided a shell script that automatically generates all this from a 1024×1204 PNG image. Of course, you can also use the online tools such as iconverticons.com/online/, cloudconvert.com to convert the icon and production.

Generate GH_TOKEN

The electron Builder needs the Github Personal Access token (GH_TOKEN) to have permission to upload files to Github Releases. The Token can be set on the Github Token configuration page. Since our CI only needs access to the public warehouse, simply check the repo > public_repo check box. This token is only displayed once and needs to be recorded, and we will use this value when configuring the GH_TOKEN environment variable in CI.

Configure a CI

You might think we don’t need CI. However, we need to build applications for three different platforms, and applications are platform dependent. You can’t build Mac applications on Linux, Linux can build Windows applications with Wine, but can you trust the quality of the built applications with such hack behavior? Normally, applications that are suitable for a particular platform need to be built on that platform. So we need CI to build Windows applications using AppVeyor and Linux and Mac applications using Travis.

AppVeyor

Here’s a simple version (but with everything you need) of Appveyor.yML

platform:
  - x64

cache:
  - node_modules
  - '%APPDATA%\npm-cache'
  - '%USERPROFILE%\.electron'

install:
  - ps: Install-Product node 8 x64
  - npm install

build_script:
  - npm run dist

test: off

branches:
  only:
    - master
Copy the code

The configuration is straightforward, and you can see what the parameters do from the field names. Note that the install section specifies the installation of Node-v8-x64 and then the installation of package dependencies. The actual build is controlled by the build_script section. Branches indicate that only master submissions are built.

Don’t forget to configure the GH_TOKEN environment variable.

You can configure variables directly in Appveyor.yml as follows

environment:
  GH_TOKEN:
    secure: <encrypt_value>
Copy the code

The < encrypt_Value > can be obtained by encrypting GH_TOKEN with tools provided by AppVeyor.

You can also configure this in project Settings

The configuration is complete.

When you submit the Master branch and the vx.xx.xx tag to Github, Appveyor will automatically build the Windows installation package and publish it to Github Draft Release.

Travis

Travis is set up similarly to AppVeyor. Add the.travis. Yml file

Osx_image: Xcode8.3 Dist: Trusty sudo: false language: node_js node_js: "8" env: global: - ELECTRON_CACHE=$HOME/.cache/electron - ELECTRON_BUILDER_CACHE=$HOME/.cache/electron-builder os: - linux - osx cache: directories: - node_modules - $HOME/.cache/electron - $HOME/.cache/electron-builder - $HOME/.npm/_prebuilds script: - npm run dist branches: only: - masterCopy the code

Language specifies node_js so we can use node and NPM. Node_js specifies the node version. Of particular interest is the OS segment, specifying Linux and OSX so that Travis can run both builds in a single commit, building deb packages and appImage under Linux and DMG and MAC under OSX.

Also don’t forget to set GH_TOKEN.

You can encrypt GH_TOKEN using the Travis command line tool

gem install travis

travis encrypt -r sigoden/alphat GH_TOKEN="<token>"
Copy the code

The command output is as follows

secure: "<encrypted data>"
Copy the code

Add

to.travis. Yml

env:
  global:
    - secure: "<encrypted data>"
Copy the code

You can also configure environment variables on the project Settings page

The configuration is complete.

When you submit the Master branch and the vx.xx.xx tag to Github, Travis will automatically build Linux and OSX installation packages when publishing to Github Draft Release.

conclusion

The configuration described above is very succinct, and while it does provide us with a build release architecture, there is still a lot to tweak for formal business applications. You may want to add native package support, App signing, publishing to the Mac App Store or Windows Store, etc. But I’m sure none of this is a big deal because it’s well documented, and CI is like a virtual machine, allowing you to install and use commands, and almost everything you do locally can be done on CI. I hope you found this article useful.