CODEWITHSUNDEEP
electronelectron-builder
SebastianR
SebastianR

Reputation: 2233

See build target of electron-builder in running application

I use electron-builder to create distribution packages of my Electron app. My app offers users the option to disable (and enable) the auto-update that's included in electron-builder. I don't want to offer this choice in cases in which the auto update doesn't work in the first place (e.g. Windows Store, Linux Snaps, Linux deb packages etc.)

I've seen that Electron has the property process.windowStore, which at least helps me find out about one of the build targets. How can I find about in which build target the Electron app runs in Linux so that I can hide the option to disable auto updates?

Upvotes: 0

Views: 1179

Answers (2)

e-remit
e-remit

Reputation: 46

You can add to devDependencies package copyfiles, then create a different config scripts like /config/windows/desktop.js, ./config/mac/desktop.js:

var Desktop = { "build": "windows" };
module.exports = Desktop;

Modify scripts part in package.json

"electron:mac": "copyfiles -f -V -E ./config/mac/desktop.js ./public/ && build && electron-builder build --mac",
"electron:windows": "copyfiles -f -V -E ./config/windows/desktop.js ./public/ && build && electron-builder build --windows",

During execution just read the Desktop object and the correct target will be visible.

const Desktop = require('./desktop');
if (Desktop.build === 'windows') //...

Upvotes: 0

Alexander Leithner
Alexander Leithner

Reputation: 3442

TL;DR: Other than checking for AppImages, Windows Store and Mac App Store, you cannot detect where your binary you're currently executing came from. The executable is the same for all packages on Linux, the package is only its container.

Besides process.windowsStore, there's also process.mas for the Mac App Store. On Linux, however, information where the executable came from (i.e. how it was installed) is lost. This is due to the fact that all package formats (Debian packages, RedHat packages, Snaps, etc.) essentially boil down to an archive which the installer (dpkg, rpm, snap, etc.) extracts to a certain location. Only those programs keep track of which files belong to which package.

If you provide your application in a manner of installable packages and not only simple tarballs, you probably will have to disable auto-update for all Linux builds. However, it may be worth checking at runtime whether the executable currently runs from a restricted directory (such as /bin, /usr, /lib, /lib64, etc.) -- this may be an indication that the user installed the app using a package:

// in the main process
if (process.platform === "linux") {
    var disableAutoUpdate = false;
    var restrictedDirs = [ "/bin", "/usr", "/lib", "/lib64" /* ... others to your liking ... */ ];
    for (var i = 0; i < restrictedDirs.length; i++) {
        if (__dirname.startsWith (restrictedDirs [i])) disableAutoUpdate = true;
    }
    if (disableAutoUpdate) {
        // your logic
    }
}

However, this is no guarantee -- the OS, the desktop environment, etc. may do some tricks you cannot possibly detect (e.g. extracting AppImages to such a destination). Also, don't test for /home (or, for that matter, /root) alone, because tarballs can be extracted anywhere. This includes user-owned directories which are not protected, not installation destinations for package installers and which are not beneath /home but rather in /mnt, /run, etc.

There's another way (which possibly works) when testing for AppImages. According to the AppImage documentation, the environment variable APPIMAGE (amongst others) will be set to the full path of the executable. Thus, you could re-write your auto-update check to something along the lines of:

if (process.platform === "linux") {
   var disableAutoUpdate = true;
   // maybe do some other checks...
   if (process.env.APPIMAGE) disableAutoUpdate = false;
   if (disableAutoUpdate) {
       // your logic
   }
}

Note, however, that this too is no guarantee, because any user may set environment variables before running any executable. This test makes false-positives just way less likely.

Upvotes: 1

Related Questions