Support Node Aliases

[wesleytodd]

Hey, I was wondering what it would take to get nvm to support these aliases?

nodejs/package-maintenance#236

Is this something you are interested in?

[ljharb]

nvm already supports lts/*, lts/dubnium, etc.

I plan to add support for lts/-1, lts/-2, etc.

The challenge around any category that depends on time (active, maintenance, etc) is that then nvm has to start storing the EOL dates from remote calls to nodejs.org, doing date math in POSIX, and knowing the current time - which is a ton of complexity.

However, CI configs using lts/*, lts/-1 would typically cover lts_active; adding lts/-2 would typically cover lts; and adding node to that would cover the current version (ie, latest active+non-LTS). Would that be sufficient?

[wesleytodd]

I open this not because the functionality is not mostly already present. I ask specifically about these aliases. The goal of that document is to formalize the grammar, and from a tooling perspective, if we had a shared grammar we could have standard ways to use these aliases in local dev (nvm), CI and even prod for how we bundle and deploy applications.

Today, because we do not have a shared grammar we get one alias in the .nvmrc, one in the engines field and then custom tooling (for example ours uses semver ranges only) to build a deployable artifact. If we can get everyone aligned on these specific aliases then we could move toward just using one location (maybe the engines field if it supported aliases like this for applications).

[ljharb]

To be honest, I don't think that time-based aliases are actually going to be a particularly good or easy thing to get adoption across the ecosystem.

[wesleytodd]

I am interested in why you think this?

For me, I really don't want to think about this. I want to just say "follow the most recent lts" or "follow the leading edge" and forget about it until there is an issue. This is obviously different for testing, but for my general local development and even for my deployments, I want less control, not more.

Obviously there will be cases to pin back and even lock, but supporting these aliases which are resolved when someone runs the tool seems like a great feature (ignoring for now the technical details).

[ljharb]

I think that node, lts/*, and the upcoming lts/-1 and lts-2 will meet this use case without needing to add the complexity of support dates.

[wesleytodd]

Ok, but support dates are inherent in the lts tags as well. I am not sure why this is different than those, and the whole point of a standard grammar is that by supporting them we can build better more integrated tooling. Maybe you have a better technical details for how you support them, but the foundation is the same no matter the alias.

[ljharb]

I don't think they are - using lts/-1 is just talking about release lines, and if node ever decides to, say, drop support sooner, or keep support longer, then that wouldn't impact those aliases. Keeping track of dates programmatically adds complexity - and thus brittleness - to any part of the ecosystem trying to do so.

[wesleytodd]

Sorry, I haven't dug into how nvm tracks LTS releases, but how does it know when a version enters LTS?

[ljharb]

The listing on nodejs.org updates to include it. To know if a version is supported, instead of one piece of information (the nodejs.org index), two/three are required (the current date and timezone) as well as the logic to compare them.

[wesleytodd]

Ok, so you just use the lts flag in the versions.json, and so all you need is the semver comparison instead of the date. This makes sense but I am wondering if there is a way we could replicate the same behavior where the data is encoded at build time into that file and enable us to support this feature without date mat in bash.

[ljharb]

The node release team could certainly add a column for "no longer supported", and then nvm could trivially read it.

[wesleytodd]

Cool, so if we had flags in that file which could be used to support these aliases you would be good with that. Then I will go ahead and engage them to see if we can get these added. I think the flags we will need added are maintenence and active, right? This will also greatly simplify the logic in @pkgjs/nv.

[ljharb]

also “EOL”, ideally