Suggestion: pre-build binaries

[matthew-dean]

I think since there are a number of tools unfamiliar to Node.js / NW.js authors required for builds (For instance, I haven't gotten the rsrc thing working yet nor do I really understand it) that you should actually distribute the pre-built binaries. In an ideal scenario, someone would add this to their NW.js project via NPM, and NPM can't really build a .go project. However, it would be trivial to get the binary path if it's already in the Node project (and copy it to the temp installation directory).

Obviously, you can include the source .go files with the binaries so that people can still do custom builds, but just add the binaries (e.g. /dist/win32/updater.exe) for each NW.js-supported platform.

The updater script needs a bit of abstraction to use this in a generic way (removing hard-coded installation folders and app names, for example), but it works really well!

[oaleynik]

@matthew-dean thanks for the feedback! Obviously, this repo is just an example, which outlines the possible strategy of nwjs application autoupdates and it would be amazing to enclose it into npm package!

I was thinking about this as well and to be honest I'm not really a big fan of including pre-build binaries into npm package. Primarily due to the fact that npm packages are installed during application build. This means we can't control which binary should be downloaded for target operating systems. However, I have in mind something like this:

import autoupdater from 'nwjs-autoupdater';
const manifestUrl = 'http://example.com/manifest.json';

// This is where we will check all the necessary folders, will check the current version of the 
// installed (if any) autoupdater binary and if it doesn't exist yet - download binary for the current   
// platform (or check latest version and download updated binary)
autoupdater.init({manifestUrl})
  .then(() => autoupdater.fetchLatest()) // If newer version available - download it
  .then(updateInfo => {
     if (updateInfo) {
      // updateInfo.updateVersion
      // updateInfo.updateFilePath // path to downloaded zip file
      // updateInfo.changelog

      // Here we can notify user and start update process
      autoupdater.update();
    }
  })

API can have whatever will be needed, but the main thing is to keep binaries somewhere outside of the npm.

[matthew-dean]

@oaleynik Clever idea! I was just thinking that the binaries weren't that large, so unused ones weren't a big deal. But yeah, platform-specific is best. Considering they need an internet connection to get an update anyway, they might as well get the latest updater. Smart. And it still meets the request to have them built somewhere for easy retrieval.

[matthew-dean]

One way I've managed this is through Github releases. See: https://github.com/Crunch/Crunch-2/blob/master/package.json

My app regularly checks the manifest on Github and links to the release for that platform. The updater component could do the same independently. Of course, if the updater was used, those packaged files (for my app) would be .zip files.

[tech4him1]

Just as long as no breaking release (API change, etc.) ever got auto-updated.