Semver support

[elsassph]

When running Set-NodeVersion , the version seem to be strictly compared, e.g. if .npmrc has 8.9.1 and I have 8.17.0 installed, I would expect this newer but compatible version to be used.

[aaronpowell]

Is that really ideal? My take on having an explicit version specified in the npmrc is that you want that version. If you just want something more loose you could do Set-NodeVersion 8 and then it'll find a version matching 8.

[elsassph]

Not sure it's ideal - it could be constrainted maybe.

The problem I have is that every time I open a terminal into a project location I run Set-NodeVersion to let it pick an appropriate node based on the project. Often it fails because I have a lot of projects with random node versions specified and I don't really want to install every single patch version of node just to avoid this error.

[aaronpowell]

Having spent some time digging around the code (I don't use ps-nvm these days, as I pretty much only use WSL2) I'm unconvinced that this change would be easy to implement.

It all boils down to https://github.com/aaronpowell/ps-nvm/blob/master/nvm.psm1#L84-L89

Basically, when you try and set a version it'll check if you've specified an exact version or a semver version, so v14.0.0 is treated like an exact version whereas v14 is a semver request.

It's simple enough to do a refactor on the if test and make it a range-query on Get-NodeVersions but then the problem cascades into https://github.com/aaronpowell/ps-nvm/blob/master/nvm.psm1#L426-L474 which returns the latest version matching the semver filter, and is a problem if you have an exact match installed.

I'm worried about doing cascading changes like this to the core functions, instead I think it's a better option to have the semver request made from the .nvmrc file instead. As I said in the last comment, I'm concerned on version selection being too smart, instead it should be the project that dictates how to version is resolved, either explicit or off a semver range.

[elsassph]

I would say that Get-NodeVersions wouldn't change - currently we have a blunt filter based on exact/partial match and this is where we could maybe optionally introduce semver matching.

I guess I'll give a try.

PS: I'm using ps-nvm with Powershell core on Mac so you could possibly use it within WSL ;)

[aaronpowell]

Get-NodeVersions is already semver-away:

aapowell@AARONSB2  ~                                                                                                                                                       [08:24]
❯ Get-NodeVersions

v14.3.0
v13.14.0

aapowell@AARONSB2  ~                                                                                                                                                       [08:24]
❯ Get-NodeVersions "14"

v14.3.0

aapowell@AARONSB2  ~                                                                                                                                                       [08:24]
❯ Get-NodeVersions ">12"

v14.3.0
v13.14.0

aapowell@AARONSB2  ~                                                                                                                                                       [08:24]
❯ Get-NodeVersions "~13.15"

Thinking about it a bit more, you could leave the bulk of Set-NodeVersion as it is, but if it fails to find the explicit match it then falls back to a semver test (Get-NodeVersion -File "~$fromnvmrc").

And I do have PowerShell Core on WSL, and Windows, so I could test the changes for 2.5.0.