shadowspawn / node-version-usage Goto Github PK

The default nenv uses exact version matching to find a prefix as intended. However, you can use symlinks to create as many aliases for the current nenv as wanted, including the use of prefixes. This is not technically a hack as the rbenv family of environment groomers all work by using the directory name to set the version, and in many of these have a plugin similar to rbenv-aliases / phpenv-aliases even automatically creates symlinks to partial versions for you. In some of these, such as jenv, however, directly manipulating the prefix directories with symlinks is a recommended / common workflow.

So please indicate that partial versions is supported for nenv through the use of prefix symlinks.

I am the maintainer of phpenv [1], and a contributor to nenv [2] and jenv [3]. I am also the maintainer of phpenv-aliases [4]. If needed, I will clone an nenv-aliases repository right now.

[1] https://github.com/phpenv/phpenv
[2] https://github.com/ryuone/nenv
[3] https://github.com/jenv/jenv
[4] https://github.com/madumlao/phpenv-aliases

avn is listed in the Compatibility Testing table as being compatible with Node.js 14, however there are multiple reports listed in avn issues of problems with Node.js > 10. The avn site has not been updated for over three years.

Should avn still be listed?

Node.js 14 enters end-of-life status on April 30, 2023, so the compatibility table using Node.js 14.15.0 as reference version becomes of limited use if it does not cover currently supported Node.js versions.

I feel like it's a little strange we have the "Win EOL" column when a lot (maybe most) of these tools don't actually work on windows. Should we have an extra column for non-wsl Windows support? It looks like we have the data already in the text

Although nvm does not officially support .node-version yet
(See nodejs/version-management#13, nodejs/version-management#21), you can use a .node-version with nvm like this:
ln -s .node-version .nvmrc

This works because, .nvmrc supports the .node-version syntax (with an without the v prefix). So .nvmrc is a superset of .node-version.

If one is careful to follow the .node-version specification here, a symbolic link from .node-version to .nvmrc is a good solution until nvm officially supports it.

BTW: volta-cli/volta#983 is considering support of .node-version and referenced this repo.

Hey, I came across your analysis via nvm-sh/nvm#794 - great work!

I think the next steps are to create a test suite, and have a few people (I'm happy to volunteer) contribute/raise issues against different managers. That project could possibly be spun out into a different org too.

What do you think? Is that something you'd be interested in pursuing?

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.

https://spaceship-prompt.sh/sections/node/