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//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.

[gniezen]

Thanks @oaleynik - nice!

[oaleynik]

@gniezen also - you are absolutely right - there is not much time I have to put there. The version I have in that repo has been working for months in my main project so I completely forgot about that README notice. Thanks for pinging me and as I mentioned in that README - I hope someday we will have such solution in NWJS out of the box :) I have some ideas on a relatively simple way to do it - when I will have a bit more free time I will try to put my thoughts together about it.

[rogerwang]

@oaleynik would you mind adding a PR for the official docs to introduce your solution? Thanks.

[oaleynik]

@rogerwang sure - #5703

[matthew-dean]

I've now tried 3 permutations for updaters, and I've found that there are none that work perfectly, especially in variations of Windows permissions. In hindsight, probably the original problem I had with the traditional node-webkit-updater was that I had an incorrect path. Using any externally-compiled executable has mixed results, because without proper app signing, or app signing that matches your original app, it's not guaranteed to execute. Even if it executes, it's not guaranteed to extract. Even if it extracts, it's not guaranteed to have the right permissions to copy into the program files folder. At my work, we're trying to build apps that can self-update without user input, and so far nothing has worked consistently (at every client's location).

As it stands now, there really is effectively no solution. That is: a solution that works 100% of the time, other than running another installer from scratch.

In contrast, in the Electron project, there's an auto-updater that has very good documentation, and the only distributable you need is a single file, because of the ASAR file format (a non-compressed indexed archive that you can mount to Node.js like a single drive). I don't know how WELL it works, just that it appears to be well-maintained.

It's really unfortunate NW.js doesn't do more for packaging and distribution, because if your apps can't be easily installed, and they can't be easily updated, then you'll struggle to make anything with mass distribution.

[baconbrad]

In contrast, in the Electron project, there's an auto-updater that has very good documentation, and the only distributable you need is a single file, because of the ASAR file format (a non-compressed indexed archive that you can mount to Node.js like a single drive). I don't know how WELL it works, just that it appears to be well-maintained.

Electron actually doesn't come with an updater. It just has compatibility with the Squirrel framework. Which is a general purpose application update framework. You will need to use an additional package that builds your Electron project with Squirrel artifacts in order to get it to work. Additionally it works with or without the use of ASARs. You can learn more about it's implementation in the autoUpdater docs. Theoretically NW.js could implement it in a similar fashion.

[matthew-dean]

Electron actually doesn't come with an updater. It just has compatibility with the Squirrel framework.

Oh, didn't know that, my mistake. Hmmm..... so each one is limited in some fashion? I wonder why this is such a hard problem?

[baconbrad]

I wonder why this is such a hard problem?

Anyone can make a basic auto updater. By basic you check for changed files, download a new file, and replace it. But say if you have a packaged NW.js or Electron project a basic auto updater is out of the question. Otherwise every update would be 30-50+ MBs for KBs or a couple MBs worth of changes. So now the only plausible updater must support delta updates. Squirrel for example is a delta update based framework which is why it is favored with Electron. With delta updates you only update the differences in the file. This however is a very complex system to create. Throw in the difficulties have having in use files blocked by the OS, multi platform, and other caveats and you really got your work cut out for you. So creating such an updater is a full time project more than it is a feature. So realistically I don't expect NW.js to create their own updater but focus on third parties and possibly build an interface for those third party solutions like Electron did.

[Arti3DPlayer]

+1

[jtg-gg]

@rogerwang, I'm done with the pull request + the documentation
#5722

[Arti3DPlayer]

why this is so complicated :( I built app for each os(win, osx, linux). Have 3 zip files. I put them on server. Now i want simple api to install update or not. But or this: i need to do a lot of commands, compile source for each os and waste more time then i spent on my app.

[rogerwang]

@Arti3DPlayer there is a solution for this feature, see #233 (comment)

And we're also developing another, proposed by @jtg-gg .

[TheJaredWilcurt]

Looking forward to an officially supported feature.

[ogimenezb]

After reading all this issue I have a question.

Are you going to make an official updater or continue to recommend community solutions?

[xeoshow]

+1
Mark

[IssueHuntBot]

@BoostIO funded this issue with $40. Visit this issue on Issuehunt

[IssueHuntBot]

@loadbalance-sudachi-kun funded this issue with $256. Visit this issue on Issuehunt

[benkoska]

If this is still relevant I wold love to work on this if someone can assign me

[DavidAccola]

I'm interested in this too. node-webkit-updater and nw-autoupdater are no longer maintained.

[d3x0r]

It looks like there's no plan for auto update - this is wonderful. I'm trying to find something that doesn't pop up with 'you need to update blah blah' especially when there's no user input available to handle it. Please maintain this stance :)

[ayushmanchhabra]

We tend to support the update solution made by community, not a built-in one. Thanks to @oaleynik 's solution and it is a good start. If you find anything we can improve in NW to make your tool better @oaleynik welcome to file an issue.

I think there is no native auto update feature on the roadmap. The stance is still supporting a community solution. Please ping if this is not the case.

[DavidAccola]

I think there is no native auto update feature on the roadmap. The stance is still supporting a community solution. Please ping if this is not the case.

Which community solution? None are maintained.

[ayushmanchhabra]

I think there is no native auto update feature on the roadmap. The stance is still supporting a community solution. Please ping if this is not the case.

Which community solution? None are maintained.

That is true for now. I'm trying to get this repo up to date:
https://github.com/nwutils/nw-updater

[d3x0r]

Just to be sure - there's no hooks in nwjs to trigger this? But an external utility can be used? If there are internal triggers is there an option to NOT do any updates? Once this works, there's no reason to ever update this anyway; neither the server nor clients will receive any updates. Much of this is casino gaming, and is controlled software that should not change anyway (there's a specific approval process that's a lot of time and money to get done anyway).

[bluthen]

@d3x0r

Never has there been an update system just for nwjs by itself, we are talking about an update system for one's specific app as a complete package. If your app has no updates there would be nothing to update. A general nwjs update wouldn't work, it isn't signed, there isn't other parts of your custom app that come with it. You are worrying to much.