show only versions newer than NVM_MIN if set

[ryenus]

This is to fix #3250.

[ljharb]

I like that it's done in awk :-) it'd be great to benchmark the difference to make sure this isn't slowing anything down meaningfully.

this will need tests, and also it'd be good to add a --min option to all the things that talk to the mirror (nvm ls-remote, nvm install, nvm version-remote) and then maybe nvm ls for good measure (altho that can be a follow-on if you like)

[ryenus]

Performance-wise there's not really much change or overhead, you can trust that awk is fast :-) Sometimes it might even run faster, esp. when many older versions are skipped.

Meanwhile the other sibling functions and even the tests are something I'm not really familiar with, may you can chime in here? @ljharb

[ljharb]

Sure - for the tests, there's existing tests for nvm ls-remote that employ mocks for the remote data, and a test that uses the env var, and asserts that it matches the mock minus the first N lines (since older versions aren't going to change, that number won't break over time), that would be sufficient. Similar approaches will work for the others.

For adding an option, if you grep for "ls-remote" you'll find the chunk of code where top-level commands are defined, and there's a bunch of existing examples that process the arguments.

[ryenus]

@ljharb just added a test, however Travis CI seems stuck, any insight?

[ljharb]

It occurs to me that

[ryenus]

As we can see from the below screenshot, for v16.15.1, now all of its updates are listed:

[ljharb]

This looks great, I'll play with it locally a bit this week.

[ljharb]

When I run nvm ls locally with this PR, I get empty as the first item in the list.

When I run nvm ls-remote --min=4 locally with this PR, all versions are displayed.

[ryenus]

• When I run nvm ls locally with this PR, I get empty as the first item in the list.

  Interesting, any idea where could this empty come from? Asking because here the change to nvm_print_versions only determines whether to skip certain versions or not, meanwhile all the versions are supplied by the caller.

  May I ask what's the output of nvm ls when run from the master branch? Asking because for me I got identical output:

  

• When I run nvm ls-remote --min=4 locally with this PR, all versions are displayed.

  As a comparison, here's what I got with the same command:

  

  Is it possible that the shell was still running the code from another branch, rather than that of the PR? Maybe check the output of type nvm_print_versions?

[ljharb]

ok, testing again, and nvm ls-remote --min=4 (or 20, or whatever) still has no effect for me on my Mac.

What OS are you using exactly?

[ryenus]

ok, testing again, and nvm ls-remote --min=4 (or 20, or whatever) still has no effect for me on my Mac.

What OS are you using exactly?

Actually I'm also on mac :-) How about NVM_MIN=4 nvm ls-remote? Can you also try to enable set -x within nvm_print_versions?

[ljharb]

ohhh wait, lol i think this is the actual feature i asked for - i have tons of node versions installed, going back a very long way:

$ NVM_MIN=4 nvm ls-remote | wc -l
     711
$ nvm ls-remote --min=4 | wc -l
     711
$ nvm ls-remote | wc -l
     790

in other words, it's filtering some things out, but with the additional logic i requested, it's still showing me a lot of things i didn't expect. 🤔

[ryenus]

ohhh wait, lol i think this is the actual feature i asked for - i have tons of node versions installed, going back a very long way:

in other words, it's filtering some things out, but with the additional logic i requested, it's still showing me a lot of things i didn't expect. 🤔

Ahh, so it's because you have just too many versions installed? Or would you change mind? Hopefully not :P

BTW, typically I just run something like NVM_MIN=18 nvm ls-remote --lts.

[ryenus]

@ljharb FYI, just rebased with some minor fix in tests.

[ryenus]

@ljharb may I ask how it is going? anything to note?

[ljharb]

No progress yet; I've been traveling. I'm prioritizing a bug fix on nvm before this PR, but it'll be next in line after that.

[ljharb]

ok, so i just tried it out again.

if i do nvm ls-remote --min=99, i get all the versions hidden below the lowest one i have installed - v0.4.12 - but i get every version higher. So, for me, it's not really that useful. I assume that on an empty system, or one where all installed node versions are above the min, it actually works as intended.

I'm starting to wonder if perhaps my original concern - about versions being hidden - is better addressed by prepending a message like "Minimum version X set: N versions hidden", and going back to the simpler logic? (i'm super sorry if this means you're doing work to undo the work i already asked you to do :-/ unfortunately sometimes it takes time and first-hand experience to really get a sense of the DX/UX of a thing)

[ryenus]

@ljharb, although in some cases it's somehow possible to have a broad range of node versions installed, but I'm sure not everyone would need to do that. I believe most people only need (a) several (if not a few), and (b) most recent, (c) typically LTS versions, installed for the project(s) they work on. Like what's shown in a previous comment:

And this is sort of the next step for the previous pr #2827, that one has improved the performance of nvm ls-remote, by reducing the time needed for a complete nvm ls-remote from about 20s down to about 2s. This pr aims to also improve the ergonomics, by showing just what's really needed, like 798 (before) vs 38 (after) as shown below, nevertheless the time taken is also reduced as a side effect:

Unfiltered	Filtered
# time nvm ls-remote --min=v0 | wc -l 798 real 0m1.253s user 0m0.246s sys 0m0.322s	# time nvm ls-remote --min=18 --lts | wc -l 38 real 0m0.545s user 0m0.154s sys 0m0.188s

Meanwhile no worries, your initial proposal actually inspired me to think more about why people would need nvm ls-remote, or even nvm: it's because people would want to find newer versions of node delivering new features, patches or whatever improvements that are not available in currently installed versions. In that sense showing new patch versions definitely helps. That works like the program automatically detects a suitable min version based on installed ones, saving the need to figuring out the closest min version to specify, which is actually nice.

[ryenus]

BTW, the error with nvm --version in the failed tests seems unrelated:

• https://github.com/nvm-sh/nvm/actions/runs/11406338964/job/31739908143?pr=3277
• https://github.com/nvm-sh/nvm/actions/runs/11406338964/job/31739908480?pr=3277

Same error also appeared in master builds

• https://github.com/nvm-sh/nvm/actions/runs/11197993535/job/31128663973