Conditionally enable electron-updater based on target (disable for MSI)

[saifelse]

• Version: 20.18.0

• electron-updater version: : 2.21.10

• Target: NSIS, MSI, DMG

I'm building an app where I'm targetting both NSIS and MSI (and DMG for macOS). NSIS for individual per-user download, and MSI for per-machine when installed by a customer's IT. The NSIS can auto-update, and the MSI would not. I'm also considering a per-machine NSIS that would auto-update.

If I install an older version of the app via an MSI installer and then blindly call autoUpdater.checkForUpdatesAndNotify(), the prompt to install the new version still happens, and when I quit the app, it looks like it installs the newer version with the NSIS installer, resulting in there being two installations, the newer one being per-user which is not ideal.

It seems like I need to conditionally handle what my target is? It seems like I'd like to either expose the target in some way to the runtime, or, possibly more generally be able to define extraMetadata per-target... but as @develar mentioned in #1955, it looks like this would require multiple CLI invocations?

Practically speaking, what are the downsides of splitting out a separate CLI invocation for MSI where I use --em? Right now, I'm using electron-webpack, publish to S3 and perform code signing (and soon to add notarizing).

Alternatively, @develar mentioned this as a possibility:

If you use webpack (electron-webpack) and want ability to build app per target — feel free to request.

Is there a possibility that this would be useful in my scenario?

Thanks!

[JohnTendik]

This is how we are doing this currently. Probably not the best method but its working for our separate release builds (standalone vs app store)

const ENV_DEV = require('electron-is-dev');
const isStandaloneBuild = !process.mas && !process.windowsStore;
const autoUpdater = isStandaloneBuild ? require('electron-updater').autoUpdater : null;

if (!ENV_DEV && isStandaloneBuild && autoUpdater) {
  autoUpdater.on('update-downloaded', () => {
    // update
  });
}

app.on('ready', () => {
  // create your window or whatever then
  if (!ENV_DEV && isStandaloneBuild && autoUpdater) {
    autoUpdater.checkForUpdates().catch((err) => {
      logger.error('Error checking for updates', err);
    });
  }
}

Actually upon second read of your question im not sure if this is what you're looking for, your use case is different than ours. :P Ill leave it up for others just in case.

[saifelse]

My current solution is to have a separate CLI invocation to build the MSI installer, electron-builder --win=msi -c.extraMetadata.myApp.autoUpdate=false, with corresponding default metadata in package.json: {"myApp": {"autoUpdate": true}} (noting similaries to scenario in #1674)

With electron-webpack, I used the following to read that value at runtime:

// AutoUpdates.js

import path from 'path';
import {app} from 'electron';
import {autoUpdater} from 'electron-updater';

function loadPackageConfig() {
  const pkgPath =
    process.env.NODE_ENV === 'development'
      // In development, we open the file relative to the actual file path
      // Number of `..` will depend on where this file lives relative to package.jsonn
      ? path.resolve(__dirname, '..', '..', '..', './package.json')
      // In production, package.json can be found at the root of the ASAR.
      : path.join(app.getAppPath(), 'package.json');
  // We don't want webpack to bundle the file, we want the version that is built with the app.
  const pkg = __non_webpack_require__(pkgPath);
  // Our package.json has a custom field with settings
  return pkg['myApp] || {};
}

export function init() {
  const config = loadPackageConfig();
  if (config.autoUpdate) {
    autoUpdater.checkForUpdatesAndNotify();
  }
}

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[saifelse]

I think there is a code change that can make this better as this problem doesn't seem to be uncommon, but I am unfamiliar with how electron-builder works under the hood, so thoughts from @develar would help. Happy to help implement a solution with guidance.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[gilisegal]

@saifelse Have you found a better solution than having a separate client invocation?