Where to download binary from

[develar]

Where to download binary from

[justinmchase]

Right now it assumes that you're using NPM, it doesn't support git as a way to get the packages. Though that probably wouldn't be too hard to support though actually. The way we are doing it, because we also don't want to publish our app to npmjs.org, is to run our own npm server.

Specifically we are running sinopia on an amazon instance. We've configured it so only we can update packages to it and it passes through to npmjs to get public packages. Public, OSS packages (such as this one and electron-plugins) are published to NPM however. Theoretically you could just put it all in npm but I think if you do proprietary apps you should probably put it on your own server to pay for the bandwidth costs. Our sinopia server caches packages on demand and will bear the brunt of the bandwidth for our users.

But regarding #3, there are actually two kinds of binaries. The first is the package itself, which is a tgz file containing, at least, the package.json and typically all of the rest of the javascript. From there the package.json can define a "binaries" section which contains URL's to other files, which must also be tgz's and can contain anything. Typically these will contain platform specific pre-built binaries from native code. NPM usually supports native addon's by expecting a developer to package their .cc files into the package itself and then compiling it upon "npm install", however with an electron application it's not reasonable to expect a user to have a compiler on their system or to all of the other tools and dependencies needed to compile addons. Thus we need a way to distribute pre-compiled binaries.

For an example of this see the electron-mumble project I am working on. It has dependencies on several other packages that require native code, such as electron-celt.

Here you can see the binaries url in the package json:
https://github.com/EvolveLabs/electron-celt/blob/master/package.json

"binaries": [
    "https://s3.amazonaws.com/evolve-bin/{name}/{name}-{version}-{platform}-{arch}-{configuration}.tgz"
  ],

Here you can see the .travis.yml file we are using to build and publish the binaries:
https://github.com/EvolveLabs/electron-celt/blob/master/.travis.yml

Here are the scripts from the electron-updater-tools project you can use to compile electron binaries:
https://github.com/EvolveLabs/electron-updater-tools/tree/master/bin

I'm happy to answer specific questions if you have them. I will be working on #3 soon and I am happy to accept pull requests on supporting github instead of NPM as a source for pulling packages.

[mhkeller]

Thanks for the quick reply. One point of confusion I have is the reference point for out of date dependencies.

For example, if I have `moment: "^1.0.0"`` in my app's package.json but there exists a version 1.0.1 on npm, will the updater say that my deps are out of date because I'm accepting all patch versions? Will it be silent if the next highest version is 2.0.0 (which my package.json dependency excludes as a viable candidate)?

For my app, I'm using this electron app as a wrapper around an expressjs app. My strategy is that for major and minor versions, I'll update the ExpressJS app, bump the version, push it to npm and then update the package.json in the electron wrapper to match the major and minor version and make a new GitHub release. Ideally, when users launch the electron app, it will see a newer version is available and update itself along with the dependency.

This way, my thinking goes, any patch versions of the ExpressJS app would automatically be updated but for new major and minor versions, the app itself would re-download. I could tell the electron app to simply take the highest version of the dependency available and never have to worry about updating the app itself for most cases, but that seems messy and I'd prefer to have some degree of control over being able to roll back to older versions.

I'll dig into more of what you have with the electron-mumble project and see what I can apply. Either way, some ability to look to GitHub releases for that repository would be great. I could commit the app to my repository and push it to npm and, I guess, point to that path as the binary location but it feels a little cleaner (and smaller file size for my repo) to handle those releases through the gh releases page.

[justinmchase]

Right now, what it does is only look for updates to your app and for plugins. When it updates either of those it will pull down the latest compatible versions of dependencies and sub-dependencies. It doesn't notify you of updates for every single 3rd party dependency update. If you thought that was necessary or desirable we could probably and an option for that or consider doing it by default.