shadowspawn / node-version-usage Goto Github PK
View Code? Open in Web Editor NEWDocument current usage of .node-version file
License: MIT License
Document current usage of .node-version file
License: MIT License
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
.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.