Support unix like lts/<NAME> for installing versions

[katcaola]

I'm part of a project where some of the developers use unix (mac/linux) and some of the developers use windows.
I'm trying to script the setup of the repository for both sets of users.

I know that this project does not support .nvmrc so my question is, why does nvm-windows not understand lts version name strings the same way as npm-sh?

As a windows user, I can't use the lts/hydrogen string the way the unix users do because when I tell nvm for windows to nvm install lts/hydrogen or nvm use lts/hydrogen, it fails. As a unix user, I also can't use the lts18 string the way the windows users do because when I tell nvm for windows to nvm install lts18 or nvm use lts18, it fails.

Is because of how the symlinking works on windows?

It would be nice for feature parity purposes to be able to specify an lts the same way no matter what system you are on.

See relevant ticket in other project: nvm-sh/nvm#3064

[coreybutler]

It's because there is no standard for installing aliases. Parity between this project and others is not a priority, because each project takes a different approach. A standard was never established within the version management working group, so there hasn't been much guidance for vm's.

That said, the unity you seek is something I hear loud and clear. I've reflected on this quite a bit over the last few years and have come to the conclusion that a new approach is warranted/needed. We now live in a world with other JS runtimes (Deno, Bun, Workerd, etc), with interoperable code becoming a priority (which is why I joined WinterCG). I feel it is too late to try to standardize around Node.js alone. This is why I've started the Runtime project, which aims to provide a consistent cross-platform experience.

https://github.com/coreybutler/nvm-windows/wiki/New-Features

[GeorgeWL]

I'd rather that it just had parity with sh-nvm when it comes to this feature. Feels like it's needlessly diverging otherwise

[coreybutler]

@GeorgeWL you're welcome to fork the project to make that happen. Neither project has the intention of following each other's every move. That said, this has been marked for consideration in Runtime.