Feature: "n upgrade" for upgrading major versions

[mourner]

One of the most common use cases for n is keeping multiple major Node versions (e.g. 8, 10, 12 — maintenance LTS, active LTS and latest) and switching between them. However, upgrading these versions is very inconvenient. Every time, you have to go through these steps:

1. Check what latest versions are available (with a combination of n --lts, n --latest and n ls).
2. Install each one individually.
3. Remove each old version manually too. n prune isn't useful because it removes all but the active version.

To make this easier and more in line with other tools like brew upgrade and rustup update, here's a proposal:

• A new command n upgrade: Install the latest available version of each installed major version. E.g. given 10.8.0 and 12.3.1 installed, it would install 10.15.0 and 12.4.0.
• Change the semantics of n prune so that it removes all old minor versions of installed major versions. E.g. if you have 8.16.0, 10.15.0 and 10.16.0, it would remove 10.15.0 (keeping the latest versions of 8 and 10 regardless of which one is active).

Alternative 1: instead of changing prune behavior, introduce prune-minor command with the proposed behavior.
Alternative 2: prune old versions as a part of n upgrade process (simplest).

@shadowspawn I could try taking a stab at a PR if the proposal is accepted.

[shadowspawn]

Nice proposal: leading with the why, and multiple ideas for how.

I was wondering why you would check for newer version separately since n lts etc install newest every time, but are you using menu to switch versions normally?

My first reaction is I prefer alternative 2 (prune per version as part of upgrade, keep it simple and target this workflow).

Historical references: some aspects of this have come up before: #384 #452

Side note 1: this would be a bit easier to implement after a switch to using index.tab instead of screen scraping, as mentioned as part of #560, but not sure when will get to that.

Side note 2: Not ready for a PR yet, but am interested in exploring idea and any feedback from readers.

[shadowspawn]

Similar prune idea mentioned in #404

[shadowspawn]

There hasn't been any upvotes on this, but I would like this myself! Personally, more for the cleanup than the updates. If I switch to a different major version I often do it by number so get the newest version anyway.

I have been wondering about syntax. I am now thinking it is probably cleaner to keep the behaviours separate and support more use cases.

upgrade: both HomeBrew and app-get use upgrade in this sense too, with update doing something different. npm has update with an alias of upgrade. git has fetch.

Would upgrade change the installed version of node if there was a newer one? (Yes?)

prune: I am leaning towards prune keeping one of each major version by default. For me at least, that would be right more often than it was wrong.

Related closed issues: #384 #452

[shadowspawn]

Just released support for deleting versions from the menu per #590. This may be convenient enough for tidying up old versions that changing prune is less compelling. See how it goes...

[shadowspawn]

This has not received any upvotes, and I think less relevant now with the ability to delete from the menu. I personally have not wished for a prune or an upgrade since then.

Feel free to open a new issue if it comes up again, with new information and renewed interest.

Thank you for your contributions.