nodenv support of partial version

[jasonkarns]

nodenv sorta supports partial version strings.

Nodenv's .node-version doesn't perform any logic or computation around the contents of the .node-version file. (other than attempting to match with & without the leading v prefix) It takes the version string from the file, and "blindly" uses it as the version to activate; and since versions are found by their directory name within $(nodenv root)/versions/, then nodenv will happily activate node 10.2 if there exists an installed node with that name. (ie, $(nodenv root)/versions/10.2/bin/node )

This also works with any text string. Back in the day when npm2 vs npm3 compatibility was a major pain, many nodenv users would duplicate node installations such that one was pinned to npm2 and another with npm3.

$(nodenv root)/versions/0.10.8-npm2/
$(nodenv root)/versions/0.10.8-npm3/

Which would expect a .node-version file containing either 0.10.8-npm2 or 0.10.8-npm3.

Intelligent partial matching

So strictly speaking nodenv, does support partial version matching. However, it doesn't support it in the likely-common expectation that the partial version will intelligently match a corresponding node named with the full version string.

This intelligent partial matching can be accomplished with symlinks. A symlink with the partial version name is created, pointing to the full version node:

ie $(nodenv root)/versions/10.2 => $(nodenv root)/versions/10.2.4

With that symlink in place, a .node-version file containing just 10.2 works as expected.

Further, in order to get "automatic" symlink creation/deletion/updating, the nodenv-aliases plugin can be used.

TL;DR

So in summary, I understand that it's probably not useful to give nodenv a full ✅ for partial string support; but ❌ is also not quite accurate. Users can use partial version strings (or quite literally, any string) and nodenv will activate the same-named node on their system. And symlinks can be used to enhance fuzzy matching.

[shadowspawn]

Thanks. I'm not sure yet what I'll try covering with the feature table. I am leaning towards only features that are fairly widely supported across the products and have not filled out the table enough to see.

nodenv together with the node-aliases plugin and --auto and node-build is close to what I had in mind.

This raises another implementation difference though. If a product supports partial matching, is it matching against the already installed versions or against the versions available from nodejs? Partial version might have too many variations to make it worth covering at all!

Work in progress...

[karfau]

I agree that the partial support should only be something that is compatible with other version managers.

• A & B work on a repo,
• A has nodenv configured properly for the string in .node-version to work and commit's it to the repo
• B uses some other tool to manage node versions that checks .node-version, but it fails because that string is not something it understands.

With all the discussion that already took place it would already be a major achievement if the non partial version can be "unified". After that we can talk about the compatibility of the different options of partial versions...

But it's of course helpful to know about the flexibility nodenv offers to basically configure on your machine what each "version" should point to (which of course also means it can mean something completely different from what it means on some other machine).

[shadowspawn]

Finished survey. I am actually slightly surprised by the wide support for partial (fuzzy) versions for .node-version. I expected some implementations to be philosophically opposed to it, like in Ruby context: https://gist.github.com/fnichol/1912050#gistcomment-682506

nodenv gets a tagged entry for now, not a pass, not a fail. Unless/until I decide to better qualify what I mean by partial, that seems appropriate. 🙂

Feel free to close @jasonkarns , but welcome to leave open for more comments. Thanks @jasonkarns and @karfau .