Electron-builder: Build AppImage for Linux

[probonopd]

AppImage is a format for portable, distribution-agnostic binary software deployment for Linux without needing root permissions or installation. (Wikipedia)

Here is an example for Atom in AppImage format:
https://bintray.com/probono/AppImages/Atom/_latestVersion#files

And here is the script which produced it:
https://github.com/probonopd/AppImages/blob/master/recipes/atom/Recipe

While it is relatively easy to package an Electron-based app as an AppImage, it would be nice if this could be automated in electron-builder.

[ghost]

oh shit, thats cool, subscribed :-)

[develar]

Sorry for dumb question, but quick search doesn't help — electron app requires libnotify and libappindicator packages — is this problem solved in the AppImage?

[probonopd]

Yes. Simply bundle them inside the AppImage. Please open an issue on probonopd/AppImages if the AppImage linked above doesn't work on one of your targeted distributions.

[develar]

Ok, got it. Cool thing that electron-builder already provides tested and functional docker images, so, first condition "Use an old system for building (at least 2-3 years old) to ensure the binaries run on older systems too" is already done.

[develar]

Sadly, that fpm doesn't support AppImage and even there is no issue.

[probonopd]

@develar Now there is: https://github.com/jordansissel/fpm/issues/1133

[probonopd]

http://www.etcher.io/ is using AppImage as their main format for distributing the Linux version of an Electron-based app. Here is their code that produces the AppImage:
https://github.com/resin-io/etcher/blob/master/scripts/build/linux.sh

[develar]

Looks like AppImage is a rescue for us (#502, #498, #242, #497). And Docker soon release dead simple docker installers for OS X and Windows.

You can expect ApImage target in several weeks.

[probonopd]

@develar cool. Let me know if you run into any kind of issues you need help with.

[ghost]

It means you will not be supporting deb and rpm any more in the future? There's some downsides to appimage too, namely it including old system binaries (I think). Will the appimageautoupdate work with electron as well? There's other tools as well, gnome flatpak, and ubuntu snappy apps that you may want to look at.

[develar]

@kunkinkan We are open source project.

I cannot in my free time test Linux Zoo and compute required packages for each format — https://github.com/electron-userland/electron-builder/issues/502 If you use opensuse&rpm — send PR or wait. i.e. — don't expect that RPM support will be polished if no-one will report issues.

you will not be supporting

As we are open source project, there is no any guarantee ;) Current priority chain — OS X -> Windows -> NSIS -> Squirrel -> deb -> rpm -> AppImage.

[ghost]

Of course, it was just a question, not a demand or anything :-) Unfortunately I'm not competent enough to contribute much to this project, I'm afraid :-) But I am reporting issues ;-)

[develar]

Why #509 is closed as backlog but this Appimage will be supported this week — see https://github.com/probonopd/AppImageKit/issues/166

[develar]

macOS: https://github.com/electron-userland/electron-builder/wiki/Multi-Platform-Build#to-build-app-for-linux-on-macos (xz required now).

linux: https://github.com/electron-userland/electron-builder/wiki/Multi-Platform-Build#linux (xorriso required now). We don't bundle xorriso for Linux for now (only for macOS).

windows: use https://github.com/electron-userland/electron-builder/wiki/Docker (docker images updated, but not yet fully tested).

Thanks a lot @probonopd for amazing format.

Please note — we pack AppImage into xz to ensure that downloaded image can be just clicked to run (otherwise image file cannot be executed because no exec permission).

libnotify and auto update will be addressed in separate issues.

[atypicalprogrammer]

Please add version tag so that we can try it :-)

[develar]

Current known "critical" cosmetic issue — icon in the Uniny dock shown only if run as app, not on click on image. https://github.com/probonopd/AppImageKit/issues/174

[atypicalprogrammer]

@devalar , still no version tag, and "dev-master" doesn't seem to work either. How can test?

[develar]

@atypicalprogrammer Release will be in 10 minutes (if Travis will be not broken again).

[probonopd]

Current known "critical" cosmetic issue — icon in the Uniny dock shown only if run as app, not on click on image. probonopd/AppImageKit#174

If you launch the AppImage by double-clicking the AppImage, then install the desktop file when asked (using the desktopintegration script) and then quit the AppImage and launch it subsequently from the menu/Unity, then the icon should be there. Is it?

[develar]

then quit the AppImage and launch it subsequently from the menu/Unity, then the icon should be there. Is it?

Yes, it is. Commented https://github.com/probonopd/AppImageKit/issues/174#issuecomment-230678526 — "I am not Linux user. On OS X I always use Spotlight/Dock to run app. On Linux" — I don't know is it real issue or not. But I am afraid we will get some issue reports about it soon (on Windows our installer has icon, and it is very strange that no easy way to have icon on Linux, cannot believe :().

[atypicalprogrammer]

Was travis broken? I still don't see next version? Sorry, just looking forward to this release I guess ;-)

[develar]

@atypicalprogrammer Yep, Travis broken. Currently, code signing issue fixed, but now npm broken. Damn. We use CircleCI for Linux and Travis for OS X. I am going to get rid of travis (or at least release from CircleCi, not from unreliable Travis).

[develar]

@atypicalprogrammer 5.11.0 is available.

[atypicalprogrammer]

OK so I don't understand it? I get a .xz file. When I double click it it asks to extract it. I select the file to extract, double click it, then it says "No applications found for "app-name". Never mind, when I drag it to the desktop it works. Why is it packed as a xz file? Is it normal that my app icon is not used?

[atypicalprogrammer]

Is there any way I can still use a system command as it appears java cannot be accessed from within the appimage? I don't want to bundle that.

[develar]

Why is it packed as a xz file?

To prevent error No applications found for "app-name". You cannot distribute only AppImage because execute flag will be cleared on download and file will be not executable. As a solution, we pack it into archive. Also, size is very small — lzma is the best (we use slow xz to pack instead of 7za because only xz preserve exec permission).

Is there any way I can still use a system command as it appears java cannot be accessed from within the appimage? I don't want to bundle that.

Sample please. Do you execute java ... from your app code? PATH is correctly set — https://github.com/electron-userland/electron-builder/blob/master/templates/linux/AppRun.sh#L17

[atypicalprogrammer]

Never mind, sorry, java seems to be working now. Thanks!

[atypicalprogrammer]

Can you tell me what the message about creating a shortcut was about ? It only showed the first time, but I don't see any added shortcut on the desktop. (only my extracted app)

[develar]

@atypicalprogrammer I am not Linux user. I tested Ubuntu — "Spotlight" search — type in app name. i. e. it is added to menu/Unity.

[probonopd]

You cannot distribute only AppImage because execute flag will be cleared on download and file will be not executable. As a solution, we pack it into archive.

That is not the recommended way for distributing AppImages, we should work out a better solution together that does not involve wrapping the AppImage inside an archive.

[develar]

@probonopd I am totally agree. But

• LZMA is better than ZIP — ~40% less size.
• I am not sure, but zip decompressing each time slightly slow down app launch.
• http://unix.stackexchange.com/questions/82578/why-is-that-when-i-download-a-binary-from-the-web-it-doesnt-have-executable-per/82579#82579

I am not linux expert, but I think no way. Or should be a some daemon on a user machine (not possible and acceptable). Mac .app is also distributed as DMG ;)

[atypicalprogrammer]

How would appimage delete leftover data? For example .config/App Name is left over after deleting the app itself.

The key idea of the AppImage format is one app = one file. Every AppImage contains an app and all the files the app needs to run. In other words, each AppImage has no dependencies other than what is included in the targeted base operating system(s).

[develar]

it is very disappointed when you download etcher app and... what, what I should do next? How do I run app? Opening terminal and chmod +x?

[develar]

How would appimage delete leftover data? For example .config/App Name is left over after deleting the app itself.

icons and desktop files are also not deleted.

[probonopd]

it is very disappointed when you download etcher app and... what, what I should do next? How do I run app? Opening terminal and chmod +x?

Right click, properties, permissions, execute as a program. Should be familiar to any Linux user, since this is standard in the Linux world.

Also see https://www.youtube.com/watch?v=7C9thHXPZd8 on an idea how to remove the need for this in the future.

Reasons for not putting an AppImage into an archive (among others):

• No need to unpack (e.g., a 700 MB file would take a couple of seconds to unpack)
• Possible for optional helper tools to manage AppImages (e.g., download, update, display in software centers etc.) - some additional functionality is planned in this area

[probonopd]

How would appimage delete leftover data? For example .config/App Name is left over after deleting the app itself.

Same is true for versions installed by the package manager, data that apps put in $HOME is never touched when you uninstall the app.

[develar]

Next release: .AppImage extension added, not packed into xz anymore according to @probonopd suggestion.

[probonopd]

Is there any known example AppImage that has been created with electron-builder, or super-simple step-by-step instructions on how to make one?

[develar]

@probonopd https://github.com/develar/onshape-desktop-shell/releases 0.5.1 uses AppImage instead of deb. Just set target — https://github.com/develar/onshape-desktop-shell/blob/master/package.json#L33

[probonopd]

Thanks @develar - how would I use this to generate an AppImage of an app already using electron-builder? E.g.,

• Get and install npm from https://nodejs.org/dist/v4.4.7/node-v4.4.7-linux-x64.tar.xz
• git clone https://github.com/BHSPitMonkey/hipchat-electron

And now?

[develar]

@probonopd hipchat-electron uses outdated 3.x version.

• edit package.json: change ^3.23.0 electron-builder version to ^5.13.1

You will get some deprecation warnings on build, but should be ok.

• edit package.json — add after "build": { ... }:

, "linux": { "target": ["AppImage"] },

• npm install
• npm run dist or npm run dist -- --linux=AppImage if you want to explicitly set target and do not edit package.json

It is better to use NodeJS 6, you can install it using package manager — https://nodejs.org/en/download/package-manager/

[probonopd]

@develar sorry if this is OT, but I would like to make sure I understand how to use this so that I can add a description to the AppImageKit wiki on how to package Electron apps. This is what I did:

# Install npm 6 and other prerequisites
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs icnsutils graphicsmagick

wget https://github.com/BHSPitMonkey/hipchat-electron/archive/master.zip
unzip master.zip
cd hipchat-electron-master/

sed -i -e 's|"electron-builder": ".*",|"electron-builder": "next",|g' package.json

npm install
npm run dist -- --linux=AppImage

It looks like an AppImage gets generated, but it refuses to work:

$ ./dist/HipChat\ Electron-1.0.3.AppImage 
/tmp/.mount_JuWoYc
installed: X-AppImage-Version=1.0.3 image: X-AppImage-Version=1.0.3
A JavaScript error occurred in the main process
Uncaught Exception:
Error: Cannot find module 'open'
    at Module._resolveFilename (module.js:438:15)
    at Function.Module._resolveFilename (/tmp/.mount_JuWoYc/usr/bin/resources/electron.asar/common/reset-search-paths.js:35:12)
    at Function.Module._load (module.js:386:25)
    at Module.require (module.js:466:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/tmp/.mount_JuWoYc/usr/bin/resources/app/main.js:4:14)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:456:32)
    at tryModuleLoad (module.js:415:12)

Looking closer, I think the desktopintegration script got installed as AppRun -- it was not intended this way, I am surprised that this works. You are assuming that the binary has the same name as the desktop file - I don't know whether that is a valid assumption. It would be safer to leave the Exec= key in the desktop file to its original value, and have AppRun parse that (this is what AppRun.c does).

[probonopd]

With most Electron apps from GitHub I tried to package as an AppImage so far, I get npm ERR! missing script: dist:

• eye-sigil/curse-linux
• khornberg/docker-indicator
• loveky/EasyHost
• mudpuddle/inviewer
• nainemom/nai-electron-quick-start

Is there a simple way to package these anyway? Or what exactly would I have to ask the upstream authors to do?

[develar]

With most Electron apps from GitHub I tried to package as an AppImage so far, I get npm ERR! missing script: dist:

dist is the name of script in the package.json. And electron-builder version must be 5+. If electron-builder version is 2, it is not easy to upgrade to 5.

• khornberg/docker-indicator — 2.
• loveky/EasyHost — 2
• mudpuddle/inviewer — 2
• nainemom/nai-electron-quick-start — 5 Only this package can build AppImage.

If no dist script in the package.json — run tool directly:

./node_modules/.bin/build --linux=AppImage

Looking closer, I think the desktopintegration script got installed as AppRun

Yes, we use own version of desktopintegration and don't use AppRun — https://github.com/electron-userland/electron-builder/blob/master/templates/linux/AppRun.sh

You are assuming that the binary has the same name as the desktop file - I don't know whether that is a valid assumption.

We generate all — desktop file, executable. https://github.com/electron-userland/electron-builder/blob/master/src/targets/appImage.ts So, I am sure, it is app error, not our error (please note, that hipchat-electron uses outdated 3.x version, so, maybe something goes wrong).

[probonopd]

You are assuming that the binary has the same name as the desktop file - I don't know whether that is a valid assumption.

We generate all — desktop file, executable. https://github.com/electron-userland/electron-builder/blob/master/src/targets/appImage.ts

I tried

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs icnsutils graphicsmagick

wget https://github.com/irccloud/irccloud-desktop/archive/master.zip
unzip master.zip
cd *-master/

npm install
npm run dist -- --linux=AppImage

and an AppImage gets generated, but it wants to execute usr/bin/irccloud when in fact only usr/bin/irccloud-desktop is there (and even the .desktop file is called irccloud-desktop.desktop).

So could it be that this is not very robust?

[develar]

@probonopd Fixed, error was in bash script.

[develar]

AppImage is a default target for Linux since version 6 (will be released tomorrow).

[probonopd]

There should be a way for application authors to have fine-grained control over what ends up in the $APPNAME.desktop file; e.g. it should be possible to contain the correct Categories= and MimeType= entries for the app.

Example: https://github.com/zaggino/brackets-electron/issues/65

[develar]

@probonopd Fixed.

should be a way for application authors to have fine-grained control over what ends up in the $APPNAME.desktop

build.linux.desktop

e.g.:

{foo: "bar"}

the correct Categories=

build.linux.category

[Skywalker13]

@probonopd

it is very disappointed when you download etcher app and... what, what I should do next? How do I run app? Opening terminal and chmod +x?

Right click, properties, permissions, execute as a program. Should be familiar to any Linux user, since this is standard in the Linux world.

Also see https://www.youtube.com/watch?v=7C9thHXPZd8 on an idea how to remove the need for this in the future.

Reasons for not putting an AppImage into an archive (among others):

No need to unpack (e.g., a 700 MB file would take a couple of seconds to unpack)
Possible for optional helper tools to manage AppImages (e.g., download, update, display in software centers etc.) - some additional functionality is planned in this area

IMHO, the AppImage should be saved in a tar file (just TAR without compression), then the executable flag will be preserved and the "unpack" is very fast.

For an end-user it's easier... I know some Linux end-users where changing the permissions is not familiar at all.

[develar]

@Skywalker13 https://github.com/electron-userland/electron-builder/issues/893#issuecomment-259479401

[develar]

Now you can run AppImage produced by electron-builder on Elementary OS also. — https://github.com/electron-userland/electron-builder/issues/1082#issuecomment-272794622

[probonopd]

I get npm ERR! missing script: dist

Running into this here again, https://travis-ci.org/probonopd/readium-desktop#L2604 - using the latest electron-builder. Do you have any idea why this might happen?

Here is the travis.yml:
https://github.com/probonopd/readium-desktop/blob/patch-1/.travis.yml

[develar]

@probonopd this project has "package" script. Instead of

npm run build
npm run dist

Just

npm run package

should be used

[develar]

https://github.com/probonopd/readium-desktop/blob/master/package.json#L26