Convenience installation feature for upgrading an installed Node.js version

[mklement0]

It would be helpful to have a convenience nvm command - e.g., nvm upgrade <newVersion> [<oldVersion>] - that bundles the following 3 operations, so as to facilitate upgrading a locally installed version:

• install new Node.js version <newVersion>
• copy global packages from version <oldVersion>, which defaults to the latest already-installed version with the same major and minor version as <newVersion>
• uninstall <oldVersion>

In other words: this command would provide in a single operation what currently requires 3 commands in sequence: nvm install, nvm copy-packages, nvm uninstall.

If any step fails, processing should abort with an error message that provides hints as to what commands to use to complete the steps manually later.

Not finding an already-installed <oldVersion> (whether explicitly specified or implied) should be considered an error.

[ljharb]

If #537 goes in, this command would likely be essentially:
nvm upgrade =>

VERSION="$(nvm ls current)"
# figure out if the current version is stable or unstable
nvm install (un)stable --copy-packages-from="$VERSION" && nvm uninstall $VERSION

The tricky part would be figuring out if the current version was stable or unstable.

Alternatively, nvm upgrade stable and nvm upgrade unstable could be supported, which said "upgrade the current version to (un)stable" and would remove the "figure it out" logic.

[mklement0]

@ljharb Actually, I was thinking that a version must always be specified (I've updated my original post to clarify), but - yes - nvm upgrade stable and nvm upgrade unstable would definitely be handy.

I've also added an optional 2nd argument to allow explicit specification of what old version to upgrade from, in case the default logic requires - deliberate - overriding (such as when upgrading to the next [odd/even] minor version, for instance).

[dantman]

+1

My use case/thought when looking if anyone else had already reported this as a bug was in simple updating of node, especially for security releases (but perhaps also feature releases in the case of the new 4 and 5 which I don't care what the minor version is anymore).

My initial idea was not to guess versions based on versions that have the same major and minor, but instead based on whatever matches what partial version number the user inputted.

In other words:

nvm upgrade 0.10 means "install the latest version matching 0.10.x (currently v0.10.41) and migrate/uninstall any other 0.10.x release installed".

nvm upgrade 4.1 likewise means "install the latest version matching 4.1.x (currently v4.1.2) and migrate/uninstall any other 4.1.x release installed".

And nvm upgrade 5 means "I don't care about minor 5.x releases, install the latest version matching 5.x.x (currently v5.1.0) and migrate/uninstall all other 5.x.x release installed".

Perhaps there are some other concerns people may have about things like nvm upgrade node potentially wiping out every other release of node (though maybe some of those can be alleviated by requiring a -f or prompt before replacing more than one version of node). But I initially thought this could work out very well because I expect most nvm users are in the habit of using nvm use 0.10/nvm use 0.12/nvm use 4/nvm use 5 and not nvm use v0.10.41.

Though I suppose there may be something else necessary for nvm users that want to switch from say 4 to 5 or 0.10 to 0.12.

[dantman]

...ok the "currently" notes on my comment are wrong. But I'm going to leave them there because the fact that I have outdated versions of 4 and 5 (especiall security fixes) in nvm is a good demo of why upgrading of node versions in nvm especially within a functional release needs to be simpler, and the issue of outdated versions needs to be considered more.

For example, this is probably a separate issue, but I think things like nvm use 0.10 should alert me once in awhile that the 0.10.x release I have is outdated and there's a new security release. This is important because while node is managed by a system package manager security updates like those automatically get installed when others are. But when node is installed via nvm instead, that attention to security updates completely disappears.

[ljharb]

@dantman nvm install 5 --reinstall-packages-from=4 && nvm uninstall 4 if that's what you'd want, but nvm isn't designed to have a "primary" version of node installed, so automatically uninstalling the previous one isn't likely to be built in.

that attention to security updates completely disappears.

When you install software, you're the one responsible for keeping up with it on whatever channels it communicates to learn about updates, security or otherwise. That distro package managers choose to handle this for you doesn't obviate your responsibility, it's just a crutch feature of a distro package manager. nvm won't be doing that, and allows you to manage your own updates.

[dantman]

@ljharb The only thing related to a 4 -> 5 transition in my whole comment was the "Though I suppose there may be something else necessary for nvm users that want to switch from say 4 to 5 or 0.10 to 0.12." tacked on at the end.

My suggestion was about updates like v0.10.32 -> v0.10.41. Nothing about primary versions, just about replacing one 0.10.x version with another 0.10.x. Which fits perfectly well with replacing v0.12.0 with v0.12.9 on the same system. I expect it's pretty rare for people to install a security fix and still want the non-patched version around (and if they do, like for testing bugs in patched and non-patched versions, nvm install already covers them).

[ljharb]

"replacing" is the part that doesn't fit with nvm. If you want one single systemwide node version, nvm will work, but that's not its purpose.

[dantman]

I don't want one systemwide version of node. I never asked for that.

The "replacing" I'm talking about, is "replacing" say v0.10.32 with v0.10.41.

Same major.minor release of node. Every other version of node in nvm (0.12, 4.1, 5.1, iojs) all untouched and still running. No single version of node.

[ljharb]

nvm install 0.10 --reinstall-packages-from=0.10.32 && nvm uninstall 0.10.32

I frequently have multiple versions of, say, 0.10, because I'm testing across patch versions, not just across minors or majors - which is also part of the purpose of nvm.