Feature Request: Allow only specifying a major version

[xavdid]

One feature I'm really missing from nvm is the ability to specify only part of a semver version.

• nvm install 14 downloads the latest 14.x.y available
• nvm install 14.16 downloads the latest 14.16.x available
• nvm install 14.16.1 installs that exact version as expected

It's super convenient for installing the latest version of a major version if you don't care about specifics.

[jasonkarns]

Most likely agreed. The work necessary here is identified by #145 and #237

node-build inherits the opinions and implementation of its progenitor, ruby-build; wherein a given runtime version gets its name from the build definition file that describes its installation. In order to support these "aliases" of a sort, we would need to make node-build capable of moving/renaming an installed runtime after installation (thereby allowing a definition file to install a runtime that does not match its own name).

I'm making an assumption here that you expect nodenv install 14 to install a node named 14.16.1, for instance. That is, the end result of nodenv install 14 is not a node version named 14, but is in fact named according to its full major.minor.patch name. Which brings along a bit of complexity. For instance, say 14.16.1 is the latest patch release of 14 and a user's node build definition store is up to date. That is, the build definition named 14 is essentially (or literally) a symlink to 14.16.1. Then nodejs drops a new release: 14.17.0; but the user has not yet updated node-build. nodenv install 14 would install 14.16.1, despite 14.17.0 being the "latest available". This mismatch is bound to cause even more confusion than already exists!

But I do agree it's worthwhile. The underlying capability for prefix moving needs to be built, and then we can begin to layer in the capability in the CLI and account for the desired ergonomics.

[xavdid]

Awesome! I don't know much about the structure of this code, but would be happy to tackle some smaller issues if you could point me in the right direction(s).

I'm making an assumption here that you expect nodenv install 14 to install a node named 14.16.1, for instance. That is, the end result of nodenv install 14 is not a node version named 14, but is in fact named according to its full major.minor.patch name.

That was the intention, yes. Basically mirroring the nvm behavior.

Re: confusion, I think it's ok in this case. Someone doing install 14 is probably not concerned with the exact version being installed (or they would specify it). They are also probably not worried about always having the latest release, just a current-ish one (at the time of install). I think it makes sense to use the latest version they have locally defined.

Similarly, if there's just the string 14 in a .node-version file, running on 14.x.y would be seen as fulfilling that.