[ls-remote] only list active and/or maintained versions

[ryenus]

What happened?

Currently nvm ls-remote --lts literally list all the LTS versions, including the ones are no longer in active and/or maintenance status.

What did you expect to happen?

The most common usage of nvm ls-remote is to check for new versions, which is only relevant for currently supported versions, namely the ones in active and/or maintenance phases.

Therefore it would make sense to allow one to only list the currently supported versions, or to exclude the no longer supported versions.

If the default behavior cannot be changed, it would make sense to introduce certain command line options, such as --supported or --no-supported.

And we can use awk to parse the nodejs release schedule json to find supported versions, with end date later than the current date, for example:

$ curl -sL https://raw.githubusercontent.com/nodejs/Release/main/schedule.json |\
  awk -vT=$(date +%F) '{if($1~/v[0-9]+/){v=$1;gsub(/[":]/,"",v);while($1!~/end/)getline;
  e=$2;gsub(/[",]/,"",e);if(e>=T)print v,e}}'
v18 2025-04-30
v20 2026-04-30
v21 2024-06-01
v22 2027-04-30
v23 2025-06-01
v24 2028-04-30

[ljharb]

No, because that's a function of time, and that's not something I want nvm's output to depend on.

[ryenus]

Hmm, even if the content of https://nodejs.org/dist/index.tab is also somehow a function of time?

[ljharb]

It's not in the sense that nvm doesn't need to know the current date/time.

[ryenus]

TBH I don't see why we cannot put it behind a flag such as --supported, meanwhile maintain the existing behaviour as default?

[ljharb]

Of course we could. However, I don't think it would be a good idea to have anything depend on "the current date", and, if there were any way for a project's preferred node version to change based on the passage of time, then it would be possible for nvm use inside a project to work one day, and stop working the next, which would be both unacceptable and violate semver.

[ryenus]

for a project's preferred node version to change based on the passage of time

Hmm, here the request is only about nvm ls-remote, with no involvement with nvm use at all.

[ljharb]

That affects nvm install as well, though.

[ryenus]

That affects nvm install as well, though.

Maybe not if it's an option only for nvm ls-remote?

I guess this request would be more appealing back when nvm_print_versions was quite slow before it was reimplemented using awk.

Nowadays it's pretty fast. But in the context of using nvm ls-remote to check for newer versions, the no longer supported versions are NOT going to get new versions at all, that's where this option can be useful, by making the output less cluttered.

[ljharb]

Is your motivation to hasten/shorten the response of nvm ls-remote? That's very different from the OP :-)

[ryenus]

Is your motivation to hasten/shorten the response of nvm ls-remote?

Well yes, that's it.

BTW, and which OP? I guess I'm a bit confused.

[ljharb]

I meant your original post.

[ryenus]

Ahh, I was actually thinking the same, maybe my OP should have been more concise :-)

[ljharb]

Would a --min=18, for example, suffice here? basically it'd all work the same except it would omit displaying anything before v18 (and i'd optimize to skip contacting iojs.org entirely when the version was >= 4, etc)

[ryenus]

Would a --min=18, for example, suffice here?

Yes, that also works! And it has the advantage of being more flexible.

Maybe we can even have it as the default? So that in the most common use case we save several keystrokes for all the users :-) Meanwhile those who want the old behavior can use --min=0.

[ljharb]

I'm not quite comfortable with that level of a breaking change just yet; but perhaps I could also add an env var that sets that value, so it's easy to set your own default?

[ryenus]

add an env var that sets that value, so it's easy to set your own default?

That would be really great! Much appreciated 👍