For now, it uses the download links from the local manifest.
It should take the new version ones.

Now, to make an app version 1.0 update to 2.0 you must have:

• in the local manifest (version 1.0):

{
    "version": 1.0,  
    "manifestUrl": "http://myapp.com/package.json",
    "packages": {
        "mac": "http://site.com/myapp-v2.0.dmg",
        "win": "http://site.com/myapp-v2.0.exe"
    },
}

• in the remote manifest (version 2.0)

{
    "version": 2.0  
    "manifestUrl": "http://myapp.com/package.json",
    "packages": {
        "mac": "http://site.com/myapp-v3.0.dmg",
        "win": "http://site.com/myapp-v3.0.exe"
    },
}

Which is a non sense and also means you have to know in advance what will be the link to download the next version (could be myapp-v3.0.17-build2843.zip)

Let's just have one good example and link to it from the readme.

Specifically this line: https://github.com/edjafarov/node-webkit-updater/blob/master/app/updater.js#L10

What's the reasoning for this? It makes it difficult to unit test our own updater code since I basically have to stub out the NW object to get it to work.

It would be cool if rather than a static URL to check for the update, it would be possible to somehow specify a url relative to the last server the app connected to. e.g. %lastServer%/client/app.zip

I request this because our app is an enterprise app which connects to the user's server and the client version needs to be relative to the server that it is connected to rather than the latest version we have for all users.

The API I assume would need to be extended to support setting what was the last connected server.

An alternative request is to extend the checkNewVersion function to specify a minimum/maximum version to return and it would somehow get that version rather than the latest.

If I get the chance I will try to add this feature, but will not be for a few months.

I'll come back and sort this later but there are caveats about where you run your original app from. I'll add a section to the readme about this. (Just for Windows)

I'm not sure if I should open an issue for this, but this seems the best place to ask this.
What is "Note that compressed apps are assumed to be downloaded in the format produced by node-webkit-builder" supposed to mean?

In OS X, it's fairly simply to use this as the file to be replaced is one. But for the Windows and Linux buils, node-webkit-updater outputs 3-5 more files besides the executable. Do this mean the .zip to be downloaded has to include those extra files as well? If that's the case, is it necessary that the binaries are in the same folder as the other files?

tl;dr What am I supposed to do with the non-executable files in the Linux and Windows output of node-webkit-builder?

I'll come back and do this. Might also need a new method.

When updating with a DMG that has a built in EULA node-webkit-updater fails silently. unpack() never calls the callback which I believe it getting stuck on this line: https://github.com/edjafarov/node-webkit-updater/blob/master/app/updater.js#L206

Ideally, node-webkit-updater would bypass the EULA like Sparkle does (check out that specific code here) or at least return an error to the callback.

Ability to monitor download progress and unpack progress would be cool.

Downloading a zip or executable as the package url doesn't work properly if the file is gzipped (like S3 assets). Submitting a PR for this

I'm on Mac and I managed to get a working updater.
The app exit and restart as it should be, but when I exit and relaunch the app, it's still the old one (that will reboot and so on ..).
Any idea ?

How does this compare to node-webkit-mac-updater?

Is there a reason why the tests aren't being automatically ran on Travis? It would help in narrowing down bugs, ensuring it works from a fresh install, etc.

Is it possible to add support for an object based url in the manifestUrl and packages.*.url fields?
This would allow custom options to be passed in to the request module for get/download calls.

I ask because in my development environment for SSL I use a self signed certificate and by default the request module will reject the certificate.

I tried passing in the object so it would be something like:

packages : {
  win : {
    url: {
      url: 'https://localhost/update.zip',
      strictSSL: false
    }
  }
}

This works nicely (esp for checkNewVersion), however it then fails when choosing the temp path to save to because it converts the 'url' to '[object Object]'.

Hello,
Thanks for the amazing plugin.

I'm reading through your code, and correct me if I'm wrong but it looks like you are using the local manifest (package.json) to get the updated application path instead of the manifestUrl version.

Step 1: Set the updater() with original manifest
Step 2: request.get() the other manifest
Step 3: Compare
Step 4: If difference launch the download()
But the download is using the local manifest, not the one that is online from the manifestUrl.

Shouldn't it update it automatically with the manifestUrl instead?

Thanks.

I'm on mac 64 bit.

When I run upd.getAppPath() and upd.getAppExec() they both return /Users

I don't understand this line of code:

https://github.com/edjafarov/node-webkit-updater/blob/master/app/updater.js#L113

Why the ../../.. ? Why wouldn't process.cwd() be adequate?

The ../../.. is what causes the path to walk up out of my project's directory and all the way down to /Users.

hallo
is it posible to support win64 & osx64 too ? Because the node-webkit v0.11.0 have now six different builds:

Linux: 32bit / 64bit
Windows: 32bit / 64bit
Mac 10.7+: 32bit / 64bit

Hi,
This is more of a question than an issue with the updater. Its just caused me quite a bit of headscratching today so thought I might ask if anyone has any suggestions.

So my current approach is very similar to the example app.
1> Run the original app and check for new versions. if new version download/unpack.
2> Run the unpacked app from the temp directory and install back to the original app location
3> Run the new app from the original app directory.

Unfortunately when I get to step 3, the new app quits during its startup (the node-webkit startup part). I suspect that this might be due to node-webkit not allowing an app with the same package.json name and same version to run at the same time, and the app running in step 2 doesn't shut down fast enough. But to be honest I have no idea. I've tried running single-instance: false and the issue still occurs. If I skip step 1 and only run step 2 -> step 3 then it sometimes works, again I think its related to the package name and version, but it doesn't seem to be consistent.

My app is quite big so maybe that is a factor in it failing? I've also disabled any reference to my app quitting itself if it errors or otherwise so I know my app is not forcibly quitting for some reason.

Normally I'd shrug my shoulders and just leave the app at step 2 running, however due to some firewall restrictions (that require admin priviledges on windows), the user would have to reauthorize the app because its in a different directory, and this is not always possible.

My current ideas for a solution, none of which are great:
1> package an updater.exe however that would mean an extra ~40mb exe file when it is packaged with node-webkit.
2> Just have a UI that shows up when completed step 2 that says 'update complete, please restart the app' ... again not great
3> Rather than packaging the .exe's just include nw.exe and an app.nw and an updater.nw, which would solve the space issue but causes annoyances with shortcuts and running the app within windows.

I'm hoping someone else might have run into this one and found a nicer solution.

code: "EPERM"
errno: -4048
message: "EPERM, unlink 'c:\Users\edjafarov\work\node-webkit-updater\test\deploy0.1\updapp\win\ffmpegsumo.dll'"
path: "c:\Users\edjafarov\work\node-webkit-updater\test\deploy0.1\updapp\win\ffmpegsumo.dll"
stack: (...)

On this step:

          upd.runInstaller newAppPath, [
            upd.getAppPath()
            upd.getAppExec()
            "update"
          ], {}

I'd like to add an extra argument to know on startup if the app is being updated or not, as opposed to just checking the length of argv. But adding an extra argument breaks the update, and upd.install/upd.run won't complete.

Also, I'm trying this on OSX meanwhile, and earlier I set the "update" argument first:

          upd.runInstaller newAppPath, [
            "update"
            upd.getAppPath()
            upd.getAppExec()
          ], {}

And this broke the update by recursively adding an "update" folder into the "app.nw" inside my Application.app with the same content than Application.app. upd.install and upd.run are receiving the same copyPath and execPath as before when it worked, but adding the extra "update" breaks it.

I'm on Linux Ubuntu 14.04 LTS and having a Uncaught Error: spawn EACCES during runInstaller that makes the app crash.
App is correctly downloaded and unpacked, paths seem to be right but error seems to be thrown in app/updater.js L275.
My app directory has 755 on my current user.

I'm trying to debug the unpacking on Windows and this is frustrating.

I think it's https://www.mkssoftware.com/docs/man1/unzip.1.asp, but not sure

I downloaded a ZIP called something like abc-123.zip into os.tmpdir().

runInstaller then assumed the executable was at <tempdir>/abc-123/abc-123.exe but unpack actually had unzipped the contents directy into the temp directory and my executable is called nw.exe so the path should've been <tempdir>/nw.exe.

node-webkit-builder and therefore grunt-node-webkit-builder (since it is now built on top of node-webkit-builder) supports custom naming of / a few different name types for the executables.

See the following from the node-webkit-builder readme:

options.appName

Type: String
Default value: false

The Name of your node-webkit app. If this value is set to null, it will autodetect the name form your projects package.json. This will be used to generate a plist file for mac.

options.appVersion

Type: String
Default value: false

The version of your node-webkit app. If this value is set to null, it will autodetect the version form your projects package.json. This will be used to generate a plist file for mac.

....

options.buildType

Type: String or function
Default value: default

How you want to save your build.

• default [appName]
• versioned [appName] -v[appVersion]
• timestamped [appName] - [timestamp];
• A function with options as scope (e.g function () {return this.appVersion;} )

And nwutils/nw-builder#30 (comment)

So how can we handle this? I'm willing to help as much as I can, but what do you think we should do?

Related: #20

The test fails for me.

• Windows 8.1
• Node 0.10.20
• npm 1.3.11
• node-webkit 0.9.2-1 (global install)

Dump:

C:\Users\Digital\Code\GitHub\updater\test

�[0m�[0m
�[0m  build app: copy current to temp�[0m
�[0m    change manifest, build from temp�[0m
�[4mRunning "nodewebkit:src" (nodewebkit) task�[24m

C:\Users\Digital\Code\GitHub\updater\test\deploy0.2\releases\updapp\win\updapp\updapp.exe C:\Users\Digital\Code\GitHub\updater\test\deploy0.2\releases\updapp\updapp.nw win C:\Users\Digital\Code\GitHub\updater\test\deploy0.2\cache\win\0.9.2\nw.exe

�[32m>> �[39mCreated a new release with node-webkit (0.9.2) for win

�[32m>> �[39m@ C:\Users\Digital\Code\GitHub\updater\test\deploy0.2\releases\updapp



�[4mRunning "copy:win" (copy) task�[24m
Copied �[36m1�[39m files


�[32mDone, without errors.�[39m

�[0m      package for [current os]�[0m
compress:win
�[4mRunning "compress:win" (compress) task�[24m

Created �[36m./test/deploy0.2/releases/updapp/win/updapp.zip�[39m (26759413 bytes)



�[32mDone, without errors.�[39m

�[0m        change manifest, build from temp�[0m
�[4mRunning "nodewebkit:src" (nodewebkit) task�[24m

C:\Users\Digital\Code\GitHub\updater\test\deploy0.1\releases\updapp\win\updapp\updapp.exe C:\Users\Digital\Code\GitHub\updater\test\deploy0.1\releases\updapp\updapp.nw win C:\Users\Digital\Code\GitHub\updater\test\deploy0.1\cache\win\0.9.2\nw.exe

�[32m>> �[39mCreated a new release with node-webkit (0.9.2) for win

�[32m>> �[39m@ C:\Users\Digital\Code\GitHub\updater\test\deploy0.1\releases\updapp



�[4mRunning "copy:win" (copy) task�[24m

Copied �[36m1�[39m files




�[32mDone, without errors.�[39m

�[0m          run built app for [os], wait for app to be updated�[0m

          �[31m  1) "before all" hook�[0m

�[92m �[0m�[32m 0 passing�[0m�[90m (4s)�[0m

I've a valid ZIP at a valid URL and the download callback gets called almost instantly. The download just ends at 0 KB. Any ideas @edjafarov?

Our first auto-update was a success. All our users got updated to the latest, but on our second update, we've seen issues with the ZIP file on some Mac computers but not all. It appears like the system is trying to unzip the ZIP before it's done downloading.

In this example, the actual uploaded ZIP is 58 MB, but one of our developers says he sees the system try to unzip the downloaded copy at 44 MB mark. We're not 100% sure this is the case, but we want to include this information just in case it helps.

Below is the error message we are seeing in the Dev Tools JavaScript console. We also see the error message when trying to unzip the downloaded ZIP via the terminal.

An error has occurred while trying to unpack the app :: 
Error: Command failed: /bin/sh -c unzip -xo /var/folders/vl/k1f7d2yx2mx7jvzgxx0k1q9m0000gp/T/synclio.zip >/dev/null 
End-of-central-directory signature not found. Either this file is not a zipfile, or it 
constitutes one disk of a multi-part archive. In the latter case the central directory
 and zipfile comment will be found on the last disk(s) of this archive. 

unzip: cannot find zipfile directory in one of /var/folders/vl/k1f7d2yx2mx7jvzgxx0k1q9m0000gp/T/synclio.zip or
    /var/folders/vl/k1f7d2yx2mx7jvzgxx0k1q9m0000gp/T/synclio.zip.zip

Please let us know if you need any more information.

Hi, there is a bug when the zip url doesn't contain the file name / contains invalid characters. For example, our update server builds urls like htttp://example.com/build.php?id=545sdfsdff48sf1cv2, but the same error can be reproduced by just using a url like http://example.com/app.zip?lol.

The error is Error: ENOENT, open 'c:\TMPPATH\build.php?id=8965c9db76b64fb9421d153476b787b2' at Error (native). I guess it's because the computed filename isn't a valid file name.

Maybe a better approach would be to inspect the headers to find a Content-disposition? Althought right now the first response headers come in after the file name has been used to unlink & create the stream.

If so, then why? node-webkit-builder & grunt-node-webkit-builder don't generate DMGs right? Can't it support ZIPs for Mac too?

For me, I use node-webkit-builder on Windows to build for Mac, Windows, Linux32, Linux64. Then I ZIP each one up. My plan is to FTP these assets up onto a server during the process too (all using gulp), so I want this to be possible cross-platform.

For a second, forget what should be in inside the ZIPs.

If you have a ZIP called a.zip, with just b.js in it, what's the path of b.js after unpacking? What's desired?

tempDirectory/b.js? tempDirectory/a/b.js?

Since e281927 and e41c864, on Windows, the contents of the ZIP is unpacked into a directory named after the basename of the ZIP (inside temp). So it would be tempDirectory/a/b.js.

If the other platforms don't do this, we should make it so.

This has come up here, nwutils/nw-builder#71 and elsewhere before (I can't find some issues where it was discussed).

The upsides are that you have smaller releases, quicker updates, etc.

From looking at Popcorn Time's source, they do this. Hopefully @sashahilton00 (who worked on it) can clear up how it works and any downsides.

When you run theirinitial installer, you get Popcorn Time.exe (which is actually node-webkit.exe renamed) in a node-webkit directory, a shortcut called Popcorn Time (in the root next to their app package.json manifest) which just calls Popcorn Time.exe. The actual app code is in a src directory.

They seem to check for updates just like we do, but then only download a ZIP containing a .nw. When the user is alerted that the new version is ready and they click to restart, the same original app (Popcorn Time.exe) is re-ran (i.e. spawns process.execPath and quits) but passes the newly extracted .nw file as an argument. So the new app (.nw) runs from the download location with the original .exe.

How does it copy itself over the old original app code in src? I don't see where in the source this is handled. Since the new app is running from the downloaded location, I assume this is an intermediary step like we have where it then copies itself to the original location and restarts itself again but this time just using the src directory.

Is it something to do with the .old and .new suffixes? The new version is extracted as *.nw.new or something like that. When preparing the update for linux the name is renamed as I would expect, but not for Windows. Not sure what's going on here or how the existing app sources are udpated.

What if node-webkit itself needs to be updated? I.e. you have yourApp-0.5 installed (which was installed with [email protected]) and an update is available to yourApp-0.6 which needs [email protected].

Are there any downsides to this approach?

Also to note

• They don't have single-instance set to false (#62)
• @sashahilton00 said in #56 that their update system isn't 100% solid.

I'm unable to update the app on windows. I get the following error
code: "EPERM"
errno: -4048
message: "EPERM, unlink 'C:\Program Files (x86)....'"

I thought maybe i have to upload the app installer as an update but when i do that i get the following error:
spawn UNKNOWN.

I have tested it on mac and it's working fine. For mac i zip the .app file and upload that as an update.

Inside tar.gz dependency.

Are there any more unsigned exectuables?

First - thanks for your effort! While integrationg your module I had an issue which appeared sometimes - the downloaded and extracted app was not launched. I guess it's because by default node-webkit apps are single-instance only and the downloaded app was launched at a time the old app was not completely shut down. Perhaps you could mention that somewhere in the readme? This issue can be avoided with

"single-instance" : false

setting in the app's packeage json.

See #52 (comment)

Just noticed that the packages are being delivered over HTTP, which makes sense, but there is no verification of the actual file that is delivered. This could lead to MITM attacks, where the attacker loads his own package into the updater, then intercepts other computer's traffic and redirects to his updater, which, once installed, gives him full access to the user's computer. May I suggest that we use the Crypto plugin (http://nodejs.org/api/crypto.html) to implement DSA signing of packages, which ensures they are the original package, with the advantage of it still being possible to deliver it securely over HTTP. This feature is an absolute must if this updater is to ever be implemented as a service/process, and certainly in a program with many users.

Hello! Great project, really useful!

I've had an issue with the unmount on my mac, because the application couldn't find the mounted dmg. So the application would just update to the latest mounted version (not the latest downloaded version).

I changed the line 'exec('hdiutil unmount ' + filename, function(err){' in updater.js:87 to 'exec('hdiutil unmount /Volumes/'+path.basename(filename, '.dmg'), function(err){' and that seems to solve the problem.

Here are the steps that occur when I use the node-webkit-updater on Windows 8.1:

1. app detects a new version available
2. new version is downloaded & unzipped to temp directory
3. app closes
4. the new app in temp directory doesn't run
5. the new app doesn't get copied from the temp directory to the app's exec/install directory

Basically the app will download the updated version and then quit, but won't relaunch the downloaded new version.

Hello

Can you add a License to your project?

Thanks!

I noticed this while working on #37.

It's an annoying problem and I'm not sure can node-webkit-updater. But if say the user starts the app by opening a folder and double clicking the .exe, then the directory can't be removed & replaced because it'll throw a EPERM / EBUSY (can't remember which).

This is just a problem with Windows and even if it was to be somehow solved, node-webkit-updater might be too low-level. I mean, a workaround could be to use an installer to put your .exe in Program Files and pin it to the start menu, add a shortcut to the desktop, etc. so the user would never open Program Files and run it manually.

It might make sense to put all logic inside separate process that will work as a service and will download and update the version of the app.
Maybe something like network installer might be a great idea. Updater will be able to download initial version of app and install it.

node_webkit_updater process will be a detached process that will run kind of local server
any node-webkit app will be able to call this server's API
give current manifest, subscribe for updates, give current app folder
if there is node_webkit_updater app will subscribe for existing
otherwise it will spawn new one
if there is a new version of app available node-webkit-updater will download it in tmp folder and ping original app for approve.
original app should approve update and teardown itself
node-webkit-updater will try to copy the app to original folder and run app
(we need to think out what error cases could be)

Should we enforce semver? I think so.

So this line would be changed: https://github.com/edjafarov/node-webkit-updater/blob/master/app/updater.js#L60

Since the package is node-webkit-updater (which is better!) then maybe the repo should be too? It'll make it easier for people to contribute too as I wouldn't be able to fork & clone this right now if I've already cloned a different repo / have a local repo called updater.

It might increase visibility / searchability too :).

Anyone experienced this? i'm slumped... everything is ok up until when the app restarts and then calls "upd.install(copyPath, function(err) {" on that command its a blank white screen of death and the app appears to be stuck in refresh mode.

Fatal error: Unable to download nodewebkit.

Not sure if I'm doing something wrong or if this is a real issue. I ran npm run deps before running npm test. I'm on OS X 10.9.5.

Can you please improve the docs? I.e. the types of all args, etc.

Or, for example:

updater:runInstaller(appPath, args, options)

Runs installer

It isn't clear what this does I think.

For me, my executable is at E:\a\b\win\nw.exe and getAppExec() returns E:\a\b\win\win.exe

I don't know much about corrupted downloads but maybe we should store the size of the package in bytes in the manifest's packages property too so we can check the size of the downloaded file on disk against what's in the manifest, before trying to unpack.