Support Node Support Aliases

[shadowspawn]

I am opening this as a parallel to nvm-sh/nvm#2170 , rather than gate-crashing the nvm issue.

FYI: @wesleytodd

The Node Aliases are: nodejs/package-maintenance#236

In general, n resolves an alias to a single resolved version. There are not any existing commands in nwhere an alias resolves to multiple versions across major version number or release streams.

The Node Aliases which specify a single version are lts_latest and current (which are currently available in n as lts and current). I see those as being relevant to a node version manager, and the version can be resolved using just the information in https://nodejs.org/dist/index.tab.

The Node aliases which cover multiple streams are all, lts, active, lts_active.
Is there any value in supporting these aliases in some way when n does not have multiple version behaviour? My feeling is that it would be inconsistent as n run all would effectively be identical to n run current, and these aliases seem more relevant in a CI setting where you want test run across a matrix of target versions.

[wesleytodd]

The Node aliases which cover multiple streams are all, lts, active, lts_active.
Is there any value in supporting these aliases in some way when n does not have multiple version behaviour?

So the way I see that working in both nvm and n is that it would compare semver and pick the highest version at the time. If you look at the implementation in @pkgjs/nv it does sort by "semverness" so in the tooling I have it just plucks the first item. If we could have the same behavior across these tools I think that would be great!

One thing brought up on nvm was that we might want the dates in the .tab or .json files produced by the build team. I think this would be a great addition and if both nvm and n came to the table on this I don't know why it would be opposed.

[shadowspawn]

Thanks for reply @wesleytodd.

So if I am (just) picking the highest version at the time, are these mappings always correct?

• all => current
• lts => lts_latest
• active => current
• lts_active => lts_latest

(i.e. no dates consulted, newest version is implicitly always active.)

[shadowspawn]

References:

A more formal list in a draft document: https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md#node-name-space

GitHub Actions discussion: actions/setup-node#26

Discussion about whether current and lts can every overlap: https://github.com/nodejs/Release/blob/master/schedule.json

Node release plan (and phases et al): https://github.com/nodejs/release#release-plan

Tool for getting node versions by common aliases: https://github.com/pkgjs/nv

[shadowspawn]

I have refreshed myself on all the links and threads I could find. The closest I can find to a canonical reference is https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md#node-name-space
but it is in draft status.

At what stage is it appropriate to add support for these aliases in a release version of n? I have not found anywhere the aliases have been "released" or finalised.

(@pkgjs/nv is at 0.0.3.)

[wesleytodd]

So if I am (just) picking the highest version at the time, are these mappings always correct?

Looks correct to me.

but it is in draft status.

That is just a process thing, we have a limited number of people participating and so some of these sit in the draft bucket for a while. This is really the reference for now: nodejs/package-maintenance#236 (comment)

[shadowspawn]

I am planning to leave these out of first implementation, revisit in future:

• all was proposed as all maintained and looks like it changed to all lines (which I like better).
• supported and maintained from https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PACKAGE-SUPPORT.md#node-name-space and https://github.com/pkgjs/nv, but not mentioned in Standard grammar/keywords to reference node release lines nodejs/package-maintenance#236

Reference: pkgjs/nv#7

[shadowspawn]

supported vs maintained now at: nodejs/package-maintenance#353

[shadowspawn]

Added supported to #619

[shadowspawn]

I was wondering about what data might be added to index.tab, and whether there would need to be dates so the file did not need to be updated for EOL state changes as well as new releases.

I did an experiment by converting schedule.json to schedule.tab and processing it in shell script to implement the support aliases without using date comparisons as such. Seems functional relying on well formatted dates in yyyy-mm-dd format and using string comparisons (in awk).

https://github.com/shadowspawn/node-schedule-tab/blob/master/nv

(Having the active and support status in index.tab would save matching up the two sources, so playing with schedule.tab as an experiment and not as the preferred option!)

[shadowspawn]

The document "Baseline practice - Document support levels" has just moved out out of draft:

https://github.com/nodejs/package-maintenance/blob/master/docs/PACKAGE-SUPPORT.md#support-target

[shadowspawn]

Shipped in n v6.6.0