any plan about auto update?

[roughsoft]

auto update is so common feature.is there any plan about it?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rogerwang]

This is on our todo list since it's an important feature.

It's a little bit tricky since we need to figure out a way to support both updating node-webkit itself and packaged apps by our users. Comments are welcome.

[Mithgol]

You probably should start by making some relatively simple first step, which is writing just a node-webkit's engine autoupdater that downloads the necessary archive (remotely hosted at http://s3.amazonaws.com/node-webkit/node-webkit-latest-sysname-procname.arcname) and unpacks.

The autoupdater should also deal with the necessity of application's restart (because you cannot replace a running executable in Windows) and have a toggle for automatic or manual updates (the latter is for users with limited and/or expensive traffic).

The next step is, I guess, adding some simple update object to the package.json manifest, and enabling the autoupdater to use some custom update sources (listed there as URLs to archives):

"update": {
   "linux32": "http://example.com/myapp-linux-ia32.tar.gz",
   "linux64": "http://example.com/myapp-linux-x64.tar.gz",
   "mac": "http://example.com/myapp-osx-ia32.zip",
   "win": "http://example.com/myapp-win-ia32.zip"
}

The autoupdater may be made to support the three different possible package variants inside those remotely hosted archives:

• folder of files,
• .nw file,
• .nw attached to the node-webkit's tail.

The autoupdater may alternatively be made to expect always a folder of files inside a remote archive, because the autoupdater may deal with the rest by itself:

• the autoupdater may create an .nw file by itself — if and where the autoupdater discovers that it's updating an .nw-packed application,
• the autoupdater may afterwards replace a former .nw tail behind the node-webkit executable — if and where the autoupdater discovers that it's updating an application attached to the node-webkit's tail.

[GroofyIT]

Might be a stupid remark, and please do correct me if I'm wrong... Though why not utilize what's already there? a.k.a. the (html5) manifest functionality for the apps themselves? Granted, it involves a bit of rethinking regarding the implementation of the packaging itself. It does make it easier to maintain application updates, just publish a new version on the webserver (manifest change)...

[RobertLowe]

@rogerwang I hope we see a simple implementation in the coming months, this is important for security.

I think when a new version of node-webkit is available/detect, it should prompt the user and update itself with the nw content from the previous executable.

The most difficult part of this is backwards compatibility. However it shouldn't be a big issue as long as you use Semantic Versioning. Perhaps the manifest file could allow for further restricting of versions (locking from updates until user-code is compatible).

[rogerwang]

@RobertLowe Could you please elaborate on the importance for security?

On the prompt thing, we'd like to consider application -- since application's developer may or may not want the prompt (or update) from node-webkit.

[RobertLowe]

@rogerwang Without auto-updates the client is vulnerable to un-patched exploits. (For example: the recent SSL vulnerable).

On the prompt thing, we'd like to consider application -- since application's developer may or may not want the prompt (or update) from node-webkit.

This could be an option in the manifest (prompt_autoupdate - true: updates are prompted immediately when detected. false: updates auto patched on load). As auto-updating forcibly could effect application state.

[rogerwang]

@RobertLowe I understand your concern. And we'd like to implement this feature soon. But please be noted that as a native runtime, we take a very different security model from Browser or other Web runtime.

[graphnode]

[...] (because you cannot replace a running executable in Windows) [...]

On windows the executable could be renamed and posteriorly deleted when the new version runs.

[Mithgol]

On windows the executable could be renamed and posteriorly deleted when the new version runs.

Generally you are right. However, renaming node-webkit may prevent some modules from running, see #199 and #344 for details.

[roughsoft]

@zhchbin ,is there any plan about this issue?

[zhchbin]

@roughsoft Hi, for myself(a student), I didn't have any experience about enabling auto update for native application though I had read some code which are relative about chrome update and its packaged app.

This is a very important feature for node-webkit!!!

[reznikartem]

Vote for this feature too. Very important thing!

[rogeru]

I fully agree this is certainly needed for an enterprise application, due to the frequent Chromium security updates.

On Sat, Mar 30, 2013 at 11:39 AM, reznikartem notifications@github.comwrote:

Vote for these feature too. Very important thing!

— Reply to this email directly or view it on GitHubhttps://github.com/rogerwang/node-webkit/issues/233#issuecomment-15676465 .

[rawberg]

is it possible to integrate with Sparkle on OSX and AutoUpdater on Windows? Google has also open sourced there update tool Omaha.

[ampgcat]

Voting for this feature as well.

[Mithgol]

Note:  Omaha does not support OS X, Linux, non-NT versions of Windows, or any NT version of Windows preceding Windows 2000 SP4.

[RobertLowe]

Rather then going native...

I think Light Table implemented it's own auto-update.

@ibdknox could you elaborate on it?

This could be a script/npm module, I think it would be the best approach as it allows for easy access/modification. Other then a couple of hooks, it's just a matter of downloading the new kit & patching assets into it.

A generic Build module & Update module could be useful.

Just my two cents.

EDIT: a Build module may also help clean up some of the nw-test code.

[ibdknox]

I push all of my assets into ~/.lighttable on startup if it doesn't exist and then just have something that looks for a tar and unpacks it into ~/.lighttable when there's an update. This works well enough for the times when I don't need to update the version of node-webkit.

My auto-updater doesn't currently handle the node-webkit replacement bit, but that should be relatively trivial as far as I can tell. Just not worth the potential cross-platform headaches right now

[ShivaanKeldon]

Hi. I'm creating a HTML5 game that will be released with NW. And it will be great to have an updater for patching my game. Any new on that feature ?

[miklschmidt]

I wrote my own auto updater too. Currently it's a seperate node-webkit application that the main application launches when there's and update, then the updater downloads a zip and overwrites old files. It works pretty well on windows and linux, haven't experimented with OS X yet. I plan on implementing different update strategies, one for replacing the updater itself, one for replacing node-webkit binaries, and one for just updating assets. I might opensource it when it's a bit more mature, together with the node server that manages the updates.

The only issues i've run into are filelocks on windows and zombie node-webkit processes on linux, but it should be rather trivial to check for those and notify the user.

[danielmahon]

@miklschmidt I know its only been 12 days but would you be willing to share what you've started for your auto-update?

[miklschmidt]

@danielmahon sorry for the late response. Here's the gist of it.. it's a little.. rough around the edges.

http://gist.github.com/miklschmidt/5903434

[danielmahon]

No worries, Im just glad you were able to respond! Ill take a look, thanks!

[jonathanrdelgado]

Just to remark, I currently use node to simply launch a sub-process, which replaces the files and launches the updated version. Obviously, this won't help on the large scale, but for a temporary fix, it works quite well.

[katanacrimson]

@jonathandelgado So long as you do a delta patch of some sort (only downloading changed stuff) that's not going to be so bad. If you're redownloading the entire thing though...

[michaelwinser]

I'll just leave this here: Sparkle http://sparkle.andymatuschak.org/ Windows port http://winsparkle.org/

In the mean time I'm building a node-webkit javascript solution. It would be great to join efforts.

[tommoor]

I have built my own version in JS, it seems to work well - however i'm now looking at signing the app and i'm 99% sure that this will break the updater as the contents of the package can't change.

[luxzeitlos]

Vote for this feature too. Its not good if everyone writes his own solution!

[guymguym]

Vote too. This will really be a great feature.

[whiskas]

vote too

[tfzxyinhao]

what's the progress about this feature now ?

[petejkim]

+1

[AndryBray]

+1 any news about it?

[StudioQuendi]

I wrote my own updater too, but only for the app (html, js and assets). So a NW updater would be great. But not an auto-updater !! Why ? Because my app is goaled to be used in prod, and I don't want NW to be auto-updated if my app doesn't support it. The best would be an auto-update only for critical issues, and a manual update (with overwrite of the package.json by the app ?) for other updates.

[jessep]

@StudioQuendi care to share your code?

[thecotne]

+1 for autoupdate

[jessep]

Just, fyi, I was about to put up $50, but then realized I wouldn't get access to the product for that, and didn't.

On Mon, Jan 13, 2014 at 3:46 AM, Jakub Szwacz notifications@github.comwrote:

Since almost everyone needs autoupdate, and it looks like no one have time to actually do it, I started crowdfunding campaign for tool with such capabilities (among others). http://www.indiegogo.com/projects/nwt-development-tools-for-node-webkit Maybe you would like to paricipate with me in this effort.

Note: Please discuss my post on the campaign page, not here.

— Reply to this email directly or view it on GitHubhttps://github.com/rogerwang/node-webkit/issues/233#issuecomment-32162482 .

[mjhamm75]

+1 for autoupdate

[commadelimited]

Another vote for updating. This is similar to how Adobe AIR manages the update process.

[geddski]

+1, pretty critical feature IMO

[danielburhans]

An example from another open source project that deals with updating a system very similar to how node-webkit runs:

TL:DR:

• Docs: https://wiki.mozilla.org/AUS:Manual
• bsdiff/packaging: https://wiki.mozilla.org/Software_Update:MAR
  • src: http://mxr.mozilla.org/mozilla-central/source/modules/libmar/

Its an older system and new things could be used as for example xml is their server response type, as JSON would be much more appropriate, but it is something thats still used today.

When comparing the two systems what I am referring to is mozillas XULRunner platform, which also uses the AUS system for updating both the runtime platform and the files that run on top of it.

I have no clue how much work it would be to build something similar for node-webkit, just trying to help further the discussion with ideas.

Thanks for all the hard work so far!

[CodeTrol]

Can somebody explain me why node-webkit should have an auto-update feature by itself? Does anybody use it as browser replacement for viewing web pages?

2014-03-10 8:38 GMT+02:00 Allclone notifications@github.com:

An example from another open source project that deals with updating a system very similar to how node-webkit runs: TL:DR:

• Docs: https://wiki.mozilla.org/AUS:Manual
• bsdiff/packaging: https://wiki.mozilla.org/Software_Update:MAR
  • src: http://mxr.mozilla.org/mozilla-central/source/modules/libmar/

Its an older system and new things could be used as for example xml is their server response type, as JSON would be much more appropriate instead.

When comparing the two systems what I am referring to is mozillas XULRunner platform, which also uses the AUS system for updating both the runtime platform and the files that run on top of it.

I have no clue how much work it would be to build something similar for node-webkit, just trying to help further the discussion with ideas.

Thanks for all the hard work so far!

Reply to this email directly or view it on GitHubhttps://github.com/rogerwang/node-webkit/issues/233#issuecomment-37156566 .

[hardchor]

@CodeTrol I can't quite make the connection between the use as a browser wrapper and the need for a auto-updating mechanism, but to answer your question: yes, we are - planning to - use it as a thin wrapper around an existing web app.

[commadelimited]

@CodeTrol Of course it should have an auto-update. That's a common function in modern desktop applications. The ability to tell the user when there's an update to the application.

[guymguym]

Updating nw core and relaunching the application is one part of auto update.

However in my case the application itself is even more frequently updated. I would want that nw will be able to load the application package (zip) from url and extract it locally for offline execution. The url will be polled to detect new version, update the local application package and reload the application.

Currently my workaround is to use a remote url in the "main" property of the package.json combined with the "node-remote" option, however this means that the application is always loaded from the internet which requires being online to start it, and also effects startup time.

Polling for new version is easy and might even require some specialised authentication depending on the application nature, but the parts of keeping the application package offline and relaunching the application from the updated package are functions that would be best if nw will provide cross-platform.

Thanks! It's an amazing project!

[tommoor]

I'm working on a little something for Mac here after the latest Mavericks update broke our previous updater - this isn't in production yet.

Contributions are welcome and I'd like to take it multi-platform in the future... right now it uses an app packaged in a .dmg downloaded from a remote host.

[CodeTrol]

I confused a little... Are we talking about updating an app or just node-webkit core? For the first condition, solution consists of 3 steps:

1. check for update (eg: 'https://mycompanyname.com/myproductname/update?current=version') with JSON response like: {version:2, files:[...]}.
2. download files mentioned in JSON.
3. update manifest file.

For the second condition, here I wrote a code in 5 minutes for you which checks for node-webkit:

require('https').get('https://github.com/rogerwang/node-webkit',
 function(response){
  var contents = '';
  response.on('data', function(chunk){ contents += chunk; });
  response.on('end', function(){
   var matches = contents.match(/<a href=\"\/rogerwang\/node-webkit\/tree\/nw\-v([^\"]+)/);
   if(!matches) console.log('updates checker is broken');
   else matches[1] != process.versions['node-webkit'] ? console.log('There is new node-webkit version avaible: v' + matches[1] + '. Please get it from here: https://s3.amazonaws.com/node-webkit/v' + matches[1] + '/node-webkit-v' + matches[1] + '-win-ia32.zip') : console.log('up-to-date: v' + matches[1]);
  });
 }).end()

(this is version for Windows and not tested yet) But what if my app would not work there (kind of bug will appear). As developer, I must to test it first before it gets to the user. Maybe it's only me distributing my apps as stand-alone applications (nw.exe+package.json+"data"). Maybe it's only me replacing icons of executable (in Windows enviroment). Maybe it's only me renaming files /^nw(\.exe)$/ to 'myappname$1'.

Just sharing my thoughts.

[hardchor]

I looked into this as part of our hack day at Sky and the general approach was:

1. Check for new version (via a JSON API similar to the one above)
2. Download new (packaged) app to tmp_dir, terminate app in app_dir
3. Run app from tmp_dir, replace / patch app in app_dir
4. Start (updated) app in app_dir, terminate app in tmp_dir
5. ?
6. Profit

I haven't really thought about how to do patched releases of packaged apps (i.e. apps packaged with nw as executables) yet, or whether it's achievable at all, but replacing the entire app seemed a good starting point.

[katanacrimson]

@hardchor Bear in mind that you may need more than just those steps. Some apps will have db schema changes which will have to be handled in the process too, meaning that there would be a requirement for some sort of hook around...step 3, perhaps?

[gunta]

+1