New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

any plan about auto update? #233

Open
roughsoft opened this Issue Dec 5, 2012 · 110 comments

Comments

Projects
None yet
@roughsoft
Copy link

roughsoft commented Dec 5, 2012

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 comment has been minimized.

Copy link
Member

rogerwang commented Dec 5, 2012

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

This comment has been minimized.

Copy link
Contributor

Mithgol commented Dec 5, 2012

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

This comment has been minimized.

Copy link

GroofyIT commented Dec 10, 2012

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

This comment has been minimized.

Copy link
Contributor

RobertLowe commented Dec 17, 2012

@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

This comment has been minimized.

Copy link
Member

rogerwang commented Dec 17, 2012

@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

This comment has been minimized.

Copy link
Contributor

RobertLowe commented Dec 17, 2012

@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

This comment has been minimized.

Copy link
Member

rogerwang commented Dec 17, 2012

@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

This comment has been minimized.

Copy link

graphnode commented Dec 17, 2012

[...] (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

This comment has been minimized.

Copy link
Contributor

Mithgol commented Feb 1, 2013

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

This comment has been minimized.

Copy link

roughsoft commented Feb 22, 2013

@zhchbin ,is there any plan about this issue?

@zhchbin

This comment has been minimized.

Copy link
Contributor

zhchbin commented Feb 23, 2013

@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

This comment has been minimized.

Copy link

reznikartem commented Mar 30, 2013

Vote for this feature too. Very important thing!

@rogeru

This comment has been minimized.

Copy link

rogeru commented Mar 30, 2013

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

This comment has been minimized.

Copy link

rawberg commented Apr 1, 2013

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

@ampgcat

This comment has been minimized.

Copy link

ampgcat commented May 14, 2013

Voting for this feature as well.

@Mithgol

This comment has been minimized.

Copy link
Contributor

Mithgol commented May 14, 2013

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

@RobertLowe

This comment has been minimized.

Copy link
Contributor

RobertLowe commented May 14, 2013

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

This comment has been minimized.

Copy link
Contributor

ibdknox commented May 14, 2013

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

This comment has been minimized.

Copy link

ShivaanKeldon commented May 26, 2013

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

This comment has been minimized.

Copy link

miklschmidt commented May 26, 2013

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

This comment has been minimized.

Copy link

danielmahon commented Jun 7, 2013

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

@miklschmidt

This comment has been minimized.

Copy link

miklschmidt commented Jul 1, 2013

@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

This comment has been minimized.

Copy link

danielmahon commented Jul 1, 2013

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

@jonathandelgado

This comment has been minimized.

Copy link

jonathandelgado commented Jul 7, 2013

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.

@damianb

This comment has been minimized.

Copy link

damianb commented Jul 7, 2013

@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

This comment has been minimized.

Copy link

michaelwinser commented Jul 11, 2013

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

This comment has been minimized.

Copy link

tommoor commented Aug 5, 2013

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.

@luxferresum

This comment has been minimized.

Copy link

luxferresum commented Sep 3, 2013

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

@guymguym

This comment has been minimized.

Copy link

guymguym commented Sep 3, 2013

Vote too. This will really be a great feature.

@DinkoMiletic

This comment has been minimized.

Copy link

DinkoMiletic commented Jun 27, 2016

Now that we have access to chrome API is it possible to use Autoupdate? @rogerwang

@oaleynik

This comment has been minimized.

Copy link
Contributor

oaleynik commented Sep 15, 2016

Here is what we do, which allows us to seamlessly update application and updater itself (yep, even on windows).

  • Start application from the index.js (instead of directly pointing it to the .html file)
  • Open main window (so user will not have to wait)
  • Create temporary folder in the system's temp directory (lets call it T)
  • Create updates folder in the T folder.
  • Download manifest file from the remote location. It has the format, which is similar to the one used in https://github.com/edjafarov/updater. For example:
{
  "version": "1.1.0",
  "createdAt": "2016-09-15T15:02:02.365Z",
  "win32": {
    "url": "https://example.com/windows-x32-v1.1.0.zip",
    "sha256": "a5db62bbe2c382534162d921ae6319ae83384256ab7f40e928a323603653e22b"
  },
  "darwin": {
    "url": "https://example.com/darwin-x64-v1.1.0.zip",
    "sha256": "e9efa23c40cf17a1d0c77227c962b5659c099959ec199782e03f162dcbbdae19"
  }
}
  • Compare local app's version with the one from manifest file
  • If app has the latest version from manifest - do nothing
  • If app is outdated - download zip archive to the updates folder created before. When it is downloaded - show notification for user using new Notification or chrome.notifications.create. If user clicks on notification - proceed.
  • Copy bundled updater executable to the folder T
  • Run copy of the updater executable using spawn in detached mode and close application. Pass path to the downloaded archive and path to the main app executable to updater using command line arguments.
  • When updater starts it unpacks zip archive to the temp directory. Than it creates backup of the old app by renaming parent directory to .bak (on macOS the Application.app will be renamed itself)
  • Move unpacked files to the new location. If all went well - delete bak, delete temp files, delete zip archive and start main application.

Now you may ask - what the heck is bundled updater executable? It is small (~3MB) golang program, which can be compiled from any platform for any platform. When you build your app you can build updater as well and put it next to the executable (for Windows and, I guess, Linux) or inside of the Resources folder (for OSX build). Due to the fact that we copy executable to the temp folder and we run it from there - entire application, nwjs platform and updater on its own can be updated.

I guess all the steps from above can be wrapped into NWJS module and updater's binary can be bundled with the NWJS builds.

I will be happy to share the example of the golang updater if somebody will be interested :)

@matthew-dean

This comment has been minimized.

Copy link

matthew-dean commented Sep 15, 2016

@oaleynik It would be great if you were to open source your updater!

@oaleynik

This comment has been minimized.

Copy link
Contributor

oaleynik commented Sep 15, 2016

@matthew-dean here it is https://github.com/oaleynik/nwjs-tiny-updater

I will add README soon. I'm not really strong in golang, so it is stupid simple and maybe can be written better, but it does its job :)

I think it can be written in any language, but I've selected golang because of its simplicity (for real, it took just several hours for me to write this updater) and because it can be compiled from any platform for any platform, which is kinda perfect for NWJS :)

@oaleynik

This comment has been minimized.

Copy link
Contributor

oaleynik commented Sep 15, 2016

@matthew-dean I've added short README. I hope it will be easier to understand what's happening :D

@matthew-dean

This comment has been minimized.

Copy link

matthew-dean commented Sep 20, 2016

@oaleynik I built a whole update solution with node-webkit-updater before figuring out that it's completely unusable with NW.js after 0.13. (The whole method relies on spawning a copy of the app that runs the installer. But after 0.13 you can only have one app instance! ARRRRG.) Trying out your solution next. Thanks!

@oaleynik

This comment has been minimized.

Copy link
Contributor

oaleynik commented Sep 20, 2016

@matthew-dean sweet! Let me know if you will have any questions. I will be glad to get more feedback. I think the overall thing can be wrapped into the nice npm module or even integrated with the nwjs natively. I really hope this will land someday in NWJS :)

@rogerwang

This comment has been minimized.

Copy link
Member

rogerwang commented Dec 6, 2016

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.

@gniezen

This comment has been minimized.

Copy link

gniezen commented Jan 24, 2017

What is the recommended auto-update solution to use for NW.js at the moment?

I realize that community contributors have limited time to work on these solutions as side projects - I just want to know where I should be focusing my time to get one of these working. Or is there another solution somewhere I'm missing?

@oaleynik

This comment has been minimized.

Copy link
Contributor

oaleynik commented Jan 24, 2017

@gniezen readme updated :) https://github.com/oaleynik/nwjs-autoupdater

The only difference - I've cleaned code a bit and used glide for dependency management

@gniezen

This comment has been minimized.

Copy link

gniezen commented Jan 24, 2017

Thanks @oaleynik - nice!

@oaleynik

This comment has been minimized.

Copy link
Contributor

oaleynik commented Jan 24, 2017

@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

This comment has been minimized.

Copy link
Member

rogerwang commented Feb 13, 2017

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

@oaleynik

This comment has been minimized.

Copy link
Contributor

oaleynik commented Feb 13, 2017

@rogerwang sure - #5703

@matthew-dean

This comment has been minimized.

Copy link

matthew-dean commented Feb 15, 2017

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

This comment has been minimized.

Copy link

baconbrad commented Feb 16, 2017

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

This comment has been minimized.

Copy link

matthew-dean commented Feb 16, 2017

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

This comment has been minimized.

Copy link

baconbrad commented Feb 17, 2017

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

This comment has been minimized.

Copy link

Arti3DPlayer commented Feb 17, 2017

+1

@jtg-gg

This comment has been minimized.

Copy link
Member

jtg-gg commented Feb 24, 2017

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

@Arti3DPlayer

This comment has been minimized.

Copy link

Arti3DPlayer commented Feb 27, 2017

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

This comment has been minimized.

Copy link
Member

rogerwang commented Feb 27, 2017

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

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

@TheJaredWilcurt

This comment has been minimized.

Copy link
Contributor

TheJaredWilcurt commented Jul 30, 2017

Looking forward to an officially supported feature.

@ogimenezb

This comment has been minimized.

Copy link

ogimenezb commented Mar 10, 2018

After reading all this issue I have a question.

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

@xeoshow

This comment has been minimized.

Copy link

xeoshow commented Jun 23, 2018

+1
Mark

@IssuehuntBot

This comment has been minimized.

Copy link

IssuehuntBot commented Sep 6, 2018

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

@IssuehuntBot

This comment has been minimized.

Copy link

IssuehuntBot commented Sep 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment