Good idea to auto-update using npm?

[Kevin Chavez]

I'm writing a cli to run on node. I'm going to distribute it using npm. I really like Chrome/Firefox's model of automatic updates.

Would it be a bad idea to simply call the following on startup, or right before the process ends?

require('child_process').exec('npm update -g package-name');

I honestly don't see why it wouldn't, assuming all users install through npm.

Anyway, don't want to mess this one up, but it's hard to test before deploying. Thought I'd ask the experts.

[Ryan Schmidt]

You're talking about updating your own module when someone runs a program installed by your module? That's probably not a good idea. Auto-updating is probably not what users expect when installing software with npm.

Also, if your module depends on other modules, this might result in other modules being updated. It's possible the developers of those other modules have released and update that is incompatible with your code, which would break your code.

Finally, it's going to get tricky to update your own module. Imagine someone runs your program "foo", and as its first step, it tries to update itself. Then what should it do? Should it exit and re-run the new version of itself? You'll have to deal with passing along all the command line arguments, environment variables, possibly even redirected file handles like stdin, stdout, stderr.

Firefox and Chrome have different autoupdate models. Firefox checks for updates when you run it, while Chrome has a separate process that periodically checks for updates. Periodically checking for updates is less problematic for users, and avoids some of the above programming problems as well.

[Peter Rust]

> Auto-updating is probably not what users expect when installing software with npm. 

I agree. If you're distributing via npm, then it should be a dev-facing product... and most developers will want to be in the driver's seat regarding when to update and if so, to what version (jumping to the next major version vs just applying patches).

Auto-updating also has a higher chance of being terminated by the user, since the user is usually not expecting the update and may not have time for it or may be concerned about compatibility problems with the new version, etc. I'm not sure how robust npm is with respect to updates that are abruptly terminated mid-stream.

I have had cli tools tell me when they were out of date and remind me what npm command to run to update them -- i think that's ideal, especially if it's keeping busy doing what it normally does while it waits on the network to find out whether it's the latest version. i've never had a cli tool installed via npm auto-update on me, i think that would be surprising & annoying.

Developers can sometimes depend on cli tools in surprising ways, for instance if they are using the tool as part of a chain and parsing the output by another tool or piping specific input from a different tool. Even though you consider a new version to be backwards compatible, they may be depending on something you didn't expect (like the exact formatting of the output) or may even have a work-around in place for a bug, such that they are actually depending on the buggy behavior.

If it's not a dev-facing tool then I would recommend avoiding npm. Node is a standalone executable and it isn't monstrous, it can be shipped with your product. That way you can send a new version of node as part of your update process, if your code depends on it.

-- peter