Can you clarify how node-webkit-builder works? about nw-builder HOT 10 CLOSED

node-webkit-builder itself downloads the prebuilt binaries of node-webkit.
I think it would only be worth it to have it build a binary that can download node-webkit if it also did other fancy installer stuff like updating. (That could be awesome, though.)

from nw-builder.

Wouldn't it? It would solve two pain points that would elevate app distribution above Adobe AIR. Adobe AIR is a crappy platform, but it has a really, really easy distribution mechanism because the distributables are small. It seems inefficient to ship a node-webkit binary with every single node-webkit app. Why not have the installer just download it if needed on the end user's computer (and, as you say, simply update the app if that's all that's needed)? It's much easier for the user and the developer. (Although, I respect it's a bit more of a complex problem to make that architecture. 😄 )

from nw-builder.

So you mean updating node-webkit itself, not the app?

from nw-builder.

I was thinking both. I'm not sure this should be in this same project, though.

from nw-builder.

I've put in work on node-webkit-updater and as much as I'd love a cross-over which would handle both in one, I can't see how it would work. An updater is a pretty custom thing, you want to show your own updating screen; add your own logic around it, etc.

from nw-builder.

you want to show your own updating screen; add your own logic around it, etc.

I don't see why either of those would be necessarily true. They are sometimes true, but for most installers, it's not a necessity. The way Adobe handled this was to set a standard for it. They set an update.xml format (which today would probably be a JSON file), where you could specify, for example, what changes were included in that update.

Even if you started with the premise that a complete copy of node-webkit should be loaded for each NW app (which still seems odd, since apps could be version-locked, or version-unlocked to node-webkit, and you could just download / update only the versions of node-webkit needed), then it still seems advantageous to not include that completely copy of node-webkit in every update of my app. It looks like node-webkit-updater sort of handles this for subsequent updates, but I'm unclear how this would work if the update is a first-time install.

I think there's a possible solution to make this work. I'd love to help figure it out.

from nw-builder.

As far as updating the entire app goes, I've built node-webkit-updater into a current project and I think I wouldn't like to sacrifice the custom stuff. Like our app checks for updates (on launch, every X hours, & on open of the about screen), then downloads in the background, unpacks it and then in the UI there's a modal to alert the user (& a new button in the main menu & about screen if ignored) to install & restart. All of this is neatly tied in with our UI, etc. I don't see how anything like that is possible or why I would settle for less.

I think users prefer how Chrome, for example, updates rather than Adobe stuff.

Unless node-webkit-builder somehow inserts a global with a public API (like node-webkit-updater's) that the app can hook into (to trigger update checks, be told when there's an update, etc.). That would be cool. So nw-builder would handle some things out of the box; checking for updates on launch & at intervals, downloading in the background, automatically installing the new version when the app is restarted next, etc.

from nw-builder.

@adam-lynch Okay, so would it be possible to share how you did that? It sounds like you're still pulling in the app "contents" for updates separate from the node-webkit piece. Does that mean that you bundle newer versions / builds separately from updates?

I'm just trying to figure out a stack with simple priorities: 1) Small distributables, 2) small / simple updates, 3) easy build packaging. #1 I'm probably willing to sacrifice if the update process is fairly straightforward for app maintaining and the end-user experience. But it sounds like you did a custom process for that?

from nw-builder.

@matthew-dean oh, no we don't separate it from the node-webkit piece.

When we build a new release we output a ZIP for each platform containing just the new content of the app (the HTML, JS, etc.) and a manifest file (see https://github.com/edjafarov/node-webkit-updater#manifest-schema). These ZIPs and manifest need to hosted somewhere.

We then manually (hoping to automate this) create installers. So for example, for Windows if you're installing the app for the first time, you use the installer .exe and that installs the app to AppData. From then on, the app itself checks the manifest periodically (wherever it's hosted online) to see if the version in the manifest is newer than the current one. If so, it downloads the revelant ZIP, moves it (which protects us against corrupted downloads), unpacks it and alerts the user.

Then the update process involves the existing app running the "new" app from this temporary location, the "new" temp app killing the old one, copying itself to the old location, running the "new" one from the old location and kills itself.

All of this is not hard to do with node-webkit-updater.

It would be nice if the node-webkit piece was seperate (to lighten the download) but not such a big deal for us. If you were doing that, it might be best to host the node-webkit downloads yourself so you wouldn't be depending on their servers in production.

I do know that when your node-webkit app (let's say node-webkit.exe) is running, that the "contents" of your app is actually copied to AppData/local/Temp somewhere. I'm not sure if a new set of contents are put there every time the app is opened or not, but it may open up an avenue to only distribute the contents (manually overwriting the files in that location yourself).

from nw-builder.

@matthew-dean
I also have an app that now runs in the same way as @adam-lynch suggests using node-webkit-updater. It sounds a little messy when its described but works quite nicely in practice.

At the moment our approach is to build the app using node-webkit-builder which (on windows) packages nw.exe and our app into a .exe file and we then distrubite it (and the other associated dll's etc) using an installer .msi. We also have a hosted .zip file which contains essentially the same data as the msi and that is downloaded by the updater and performs the installation. At the moment this is the easiest way to auto-update the whole of the app including node webkit.

I am currently in the process of changing that approach however to something similar to what I believe you want. Basically I'm planning to no longer package the .nw file in with the .exe and rather keep them separate. This way I will have 2 update files. 1 for node-webkit and 1 that is just the .nw file. So any minor updates (i.e. any update where the node-webkit version doesn't change) I only need to download the .nw file for the update process rather than the full node-webkit + .nw file.

I'm doing this through my own custom code which grabs a .json file off the server telling me essentially whether I need a full update (if the node webkit version is different) or only a minor update. Then can download the appropriate files and upgrade. So most of the time it will only be ~1-2mb update rather than ~35mb.

Note with packaging the .nw separately, in windows (can't speak for the other platforms), if you want your app to run automatically by double clicking on nw.exe then you'll need to call the nw file package.nw and put it in the same directory as nw.exe otherwise need to create a .exe wrapper that will call nw.exe appname.nw or a shortcut to nw.exe with the command in the shortcut.

Sorry for the long post. I wish it were as simple as having a seamless auto-update already built into node-webkit, however these tools are pretty powerful and you can get your own customized auto-updater running in a couple of hours with quite a lot of flexibility.

from nw-builder.