Nvm: Install using LTS name

[jcpst]

Now that there's LTS versions of Node, it would be cool to be able to pull them down by their release names. ex: nvm install argon

[ljharb]

Hm, interesting idea. nvm alias argon 4.2 will give you this for now.

I'm not convinced yet that people will a) use or recognize the LTS names, or b) want that as a default alias at all times. However, it's relatively trivial for me to add it as a default alias. I'll think on it.

[terinjokes]

I had a Twitter discussion with @ljharb and @rvagg about this.

Looking at index.json and index.tab right now, I see that the LTS metadata base been added.

[cloud-walker]

Why not just an alias for the latest LTS available?

nvm install lts

[rvagg]

You need to be a bit careful with a blanket lts designator, there will be overlaps, my advice would be to require an explicit designator for v4.x / Argon, whatever that might be. For the NodeSource Linux distros we're just maintaining a v4.x channel that, once you install it, will only provide you with v4.x releases, even after v4.x is long-dead, i.e. you have to explicitly update to a different major.

for reference, the LTS overlaps can be seen below:

[ljharb]

The existence of "stable" and it's replacement "node" is something I regret; blindly updating past a major version is a bad idea imo. For the same reason, I don't want to add "lts" - just each individual LTS name.

[cloud-walker]

mmm, I can understand @ljharb motivation about that.

It was just a lazy need of "install the latest LTS on my fresh laptop".

[terinjokes]

To be fair, I'm not a fan of 'lts", but would be fine with "argon"

[ljharb]

Currently, to list node versions older than 0.5.1, I need to scrape HTML rather than downloading index.tab like i can do for io.js. The LTS information is in index.tab.

Since nvm ls-remote foo greps the entire list, I need all of the list every time - so I'd have to do two downloads to be able to get LTS information.

I'm still thinking about this, but unless index.tab can be updated to list all node versions back to v0.1.14, I don't have an easy solution in mind.

[rvagg]

you could hardwire them, they're not going anywhere and the list is not going to change over time, putting them in index.tab would pretty much be the same as hardwiring them in

also, do you know of anyone that uses any of those versions? I've heard vague rumours of 0.4 usage in the wild but perhaps nvm can just put its foot down and tell people to move on.

[rvagg]

https://nodejs.org/dist/index.tab :tada:

I made directories for each of these old versions to match and put a symlink in pointing back to the source file in the parent directory and even added a SHASUMS256.txt (every directory has one now fwiw)

[terinjokes]

Look at this awesome LLLLLTS. :)

[ljharb]

@rvagg Thanks!

I'd rather not drop support for older nodes if I can help it - although I can't even install node 0.4 anymore because of some 64-bit compiler error :-p

If I can ever add SHA-256 support in a POSIX-compliant way (#664) then the SHASUMS256.txt files will help greatly!

[sindresorhus]

I think a lts alias would be useful. In many of my modules, like CLI tools, I only care about supporting the latest stable and latest lts.

[terinjokes]

@ljharb with 5.0.0 out, I'd now like to be able to run CI against "stable" and "argon". Any chance we'll get LTS names added?

[ljharb]

"stable" is a concept that no longer exists - every version of node is now stable, since semver doesn't communicate stability, only breakage. You'd want "node" and "argon".

For now, you'll still need to use "node" and "4.2". This is still something I'm considering but I won't have time to do it in the near future.

[terinjokes]

@ljharb noted, but still looking forward.

[EthraZa]

Today I did:
$ nvm install lts
Version 'lts' not found - try nvm ls-remote to browse available versions.

:+1:

[mooncakelmn]

nvm install argon

+1

[ljharb]

No need for +1s please - I'd rather not lock the thread in the meantime :-)

[rcrichton]

I currently have default -> stable (-> v5.0.0) what I'd like to be able to do is point the special default alias at the latest LTS release instead. Something like default -> lts (-> v4.2.2).

I think that is generally something that people would want to do.

[ljharb]

@rcrichton nvm alias lts 4.2 && nvm alias default lts will do that for now.

[rcrichton]

Yeah, until the next LTS. I was stating how I think it should work in the long run. An, LTS alias built in seems ideal.

[mikeyhew]

@ljharb nvm alias argon 4.2 doesn't actually make nvm install argon possible - see #917

[stevemao]

I think a lts alias would be useful. In many of my modules, like CLI tools, I only care about supporting the latest stable and latest lts.

:+1:

[terinjokes]

@stevemao for the sake of those of us still stuck on the older LTS releases (I have a list of bugs in external modules that have to be fixed, merged, and published before we can upgrade… and these are the ones I know about!), I hope you continue to test them—at least for a little bit

[stevemao]

@terinjokes I actually wish travis had an option for testing on the most used node versions. There are too many node versions and they release a new major very frequently, I don't want to always update my .travis.yml files.

[ljharb]

@stevemao it's really trivial to keep https://github.com/ljharb/is-callable/blob/master/.travis.yml up to date tho :-)

[stevemao]

@ljharb I hope your joking :)

Sharable .travis.yml would be cool I think :)

[ljharb]

I agree that would be cool, but no, I'm not joking. They release a new minor version once or twice a month at most, it's really not a burden.

[stevemao]

Hm... I need a script to do that to all my repos :)

[ljharb]

make a github bot that can make prs :-p

[stevemao]

make a github bot that can make prs :-p

:+1: great idea.

[terinjokes]

@stevemao It might be something the greenkeeper guys might dig.

[terinjokes]

@ljharb just want to loop back on this, since the security update moved "argon" from 4.2.x to 4.3.x.

[ljharb]

Definitely, I figured this would come up again. https://github.com/creationix/nvm/issues/917#issuecomment-166541764 is the blocker issue.

[jasnell]

btw, if there's anything we can do on the node.js lts side, definitely let us know. To be certain, "argon" would refer to anything >= v4.2.0, including all minor bumps. In the next few weeks we're looking at a 4.3.1 followed soon after by a 4.4.0. After 4.4.0 there are no other minor bumps _currently anticipated_ but they're possible if a security fix comes up or we get another stack of semver-minor commits that users are demanding be included.

[ljharb]

@jasnell since https://nodejs.org/dist/index.tab now has the "lts" tab, i don't think there's anything you could help me with except making PRs :-D

[listepo]

+1

[ljharb]

@philkunz yes, thank you, that's the sole purpose of the PR.

This is currently blocked on https://github.com/creationix/nvm/issues/917#issuecomment-166541764.

[ljharb]

At the moment, this is only an issue when argon's minor version bumps, which happens rarely, and will be more of one when the next LTS comes out. Over time this feature will become more and more useful, obviously, but it's not particularly urgent right now. Just watch the normal channels for a release, like a responsible dev does for all the software they depend on :-)

In the meantime I'll keep trying to solve #917, and PRs are always welcome.

[janoskk]

It would be great if we can see the latest available version of each LTS when calling ls-remote. Use different color or take a note like

         v4.3.2
         v4.4.0
->       v4.4.1
         v4.4.2
         v4.4.3 (most recent version of Argon LTS)
         v5.0.0
         v5.1.0

[ljharb]

@janoskk can you file a separate issue for that? That sounds like something I _can_ do relatively quickly.

[janoskk]

@ljharb thanks, please see #1063

[coreyzev]

I think the simplest solution would be to add semantic versioning.

I'd like to say nvm install >=4.2 and that would allow me to put that in my docs and let people update from then on with the most recent version of LTS.

I agree with @ljharb that people will not generally know "argon" or other english names. I think either using semantic versioning OR prompting the user WHICH LTS version (by major version number) they want (if more than one exists).

Thanks

[ljharb]

Parsing semver is just not a practical option in POSIX. See #1070 for my (in progress) solution to this issue's problem.

[rvagg]

there's plenty of prior-art to this you could build on if you really want semver, e.g. https://github.com/cloudflare/semver_bash

[terinjokes]

@rvagg wow. I've forgotten that existed. :D

[michrome]

For anyone else arriving here from Google. To install the latest LTS release, run nvm install --lts.

[ljharb]

Feel free to also click through to #1149 and read all about the feature.

[mtebele]

It would be great if we could set LTS as default with nvm alias default lts

[ljharb]

@mtebele you can. nvm alias default lts/*.

[BBlackwo]

Is it possible to add lts to a .nvmrc file? When I try to use it nvm use I get an error:

"N/A: version "lts -> N/A" is not yet installed."

[ljharb]

@BBlackwo nvmrc requires lts/* or lts/boron etc - ie, the alias names, not the CLI shortcut names.