When I try to build nodenv in Windows Subsystem for Linux bash, I get an error about some of the line endings:

Trace

.nodenv (master)$ src/configure && make -C src
: invalid optionine 2: set: -
set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]
src/configure: line 3: $'\r': command not found
src/configure: line 5: $'\r': command not found
src/configure: line 20: syntax error near unexpected token `$'in\r''
'rc/configure: line 20: `case "$(uname -s)" in

Workaround

$ sudo apt-get install tofrodos
fromdos libexec/*
fromdos completions/*
direnv reload

If I want to 100% pass-through the line endings between my local file system and the git remote, which git settings should I use? I code on both Windows and Linux, so I don't want to force my projects to either LF or CRLF, but simply respect line endings on a per-file basis.

I'm using nodenv with boxen. I have a node application that inspects the PS1 environment variable to see what the current command line prompt is. (It needs to pass this environment variable then to other programs it forks).

However it seems like either nodenv or boxen are removing this variable. All environment variables of the form PS* (where * is a digit) are blocked and not accessible through process.env.PS1.

Any idea of what may be causing this ?

I'll be the first to admit it's of questionable utility and near-zero originality, but I decided that I needed something like nodenv-default-packages, and so I made it.

It seems like this'd be the kind of thing worth putting on a wiki list, a la rbenv, but I can't seem to get to it. Clicking the wiki icon just changes my browser's pushState.

Say I have 2 projects that use different versions of coffee-script, and I'd like $ coffee to run the local version from each project directory. I'd also like to globally install some version of coffee-script so Atom plugins don't explode. Is this possible?

I got stuck at the point where shims are added first in my path. Seems like a globally installed module always takes precedence...

I spoke with @wfarr about the nodenv org. Apparently, he wasn't the org's creator, but was invited as a member. He has invited @OiNutter as an owner so we should be able to begin using the nodenv org for nodenv and all the related plugins.

Opening this issue as a place for discussion and tracking the 'migration'

@OiNutter once you are in the nodenv org, would you mind adding us maintainers, as well?

Story: I installed ocaml with homebrew, after that installed reason-cli with npm with -g, it appears that reason-cli shadows ocaml binaries, so I uninstalled reason-cli. But nodenv still keeps shims. I can remove them manually with rm -rf, but they reappear again after shell restart. Tried nodenv rehash, but without success. How to stop nodenv from creating those shims?

These are the proper steps, at least on Homebrew for Mac OS X 10.9. The difference is line 3:

$ brew update
$ brew tap jawshooah/nodenv
$ brew install nodenv
$ brew install --HEAD node-build

nodenv install seems broken when running from boxen. When running nodenv install --list, I get:

nodenv: unable to install NodeJS `--list' from binary, download not available

I get the same message when trying to nodenv install 0.12.7 or any other version not currently installed. Perhaps I'm just being an idiot but I've been hacking on this for an hour and need to move on to other things. I appreciate any help I can get.

Need to generate changelog and post a github Release

similar to node-build: https://github.com/nodenv/node-build/blob/259a4597f4a7ac814be97d6500d7df4b24d581ad/script/release#L39-L43

It'd be great if install instructions were npm install -g nodenv. Kind missed the mark on that by a mile by not ever releasing onto npm, as someone made a different project and released it in early 2015, so you lost the name, but using some other name in package.json to make this accessible & easy to install would be great.

I am aware that this is a C project. I have plenty of non JS projects on npm, as do others. The package infrastructure ought be flexible enough to still run your existing configure and make.

Would be great to see install drastically simplified, and npm install -g really seems like the sweetest spot for that.

From the README.md:

$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bash_profile

Ubuntu Desktop note: Modify your ~/.bashrc instead of ~/.bash_profile.

The primary suggested option for step 2 I think is only required for Mac OSX (not a mac user, but this is my guess). It actually won't work for any Debian/Ubuntu and I'm pretty sure SUSE as well. The alternate option suggested for Ubuntu Desktop is therefore required for all Debian/Ubuntu/SUSE and also will work for CentOS/REHL because .bashrc is sourced by .bash_profile.

I can make a pull request with edits but wanted input from maintainer first.

Looking at https://github.com/OiNutter/nodenv/blob/master/LICENSE I'm missing any mention of the name Sam Stephenson. As the rbenv LICENSE states: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." Since this project is a substantial clone of rbenv, not including the original copyright notice seems like a violation of their license. Besides, it also seems rude to not even mention the original project anywhere in the readme.

I am trying to create an Ansible role to automate installing nodenv on Ubuntu, but I would like to know what version of nodenv to install?

So there is the master branch, which by default would be used if you fallow the install instructions. And then I also see tags (latest is v1.0.0).

• v1.0.0 is tagged on 27 Dec 2015.
• Last commit on master is on 21 Dec 2016.

A total of (721 - 636 =) 85 commit's and roughly 1 year since the last tag.

So to summarise my questions:

• What are your recommendations for development and production environments?
• Can there be a new release (tag)?

When running nodeenv -p it always redownloads the node package. I was wondering if there was a way to cache node locally and pass a parameter so that nodeenv -p will downloaded from a local repo instead?

I'm just wondering if nodenv is thinking about including an option install io.js ?

Hi,

Im using nodenv on centos, I'm trying to install 6.9.2 - but nodenv claims definition not found: 6.9.2.
(this after successfully installing 6.9.2 on windows using nodenvs younger brother nodist).

When I'm running nodenv install --list I'm getting such an immediate response (without 6.9.2 in it) that I don't think it's really checking for available versions on the web, but I could be mistaking...
git pull sais Already up-to-date.
Is there a local cache I should clear?

Help?

Hey!

Is there any possibility of being able to support versions formatted like 0.12 or even 5, where it would match the latest version installed that still matches the string prefix? I'm looking to move from nvm and avn (which do support this format) to nodenv but most of our repos are specified in this format which means nothing is working.

I'd be happy to submit a PR if this is something worth supporting!

Thanks!

System: Mac OS X El Capitan 10.11.2
Shell: zsh

Hey guys,

I just fiddled around with nodenv (installed with homebrew) and tried to install a package. Since I'm used to rbenv, I figured:

rbenv is for ruby; ruby package manager is gem.
nodenv is for node; node package manager is npm.

rbenv is set up so gem puts all the gems into the .rbenv folder corresponding to the version.
So I thought, nodenv does the same.

But by default, so it seems, npm install puts the node packages (do they have a name, too? like "gem"?) into the current directory. npm install grunt from the home directory, puts the files into ~/.npm and ~/node_modules.

I had to add the -g flag to use the ~/.nodenv folder: npm install grunt -g

Since I am not an expert programmer, this took a while to figure out. Is this intended behavior or do I have my system set up wrongly?

If it's not my error, might I suggest adding this info into the docs, so people not used to node and npm can find it easily?

Edit: gruntis now installed into ~/.nodenv/versions/5.5.0/lib/node_modules. But it still doesn't show up in $PATH.
Edit2: Yeah, it looks like the shims somehow don't update on my machine. Really weird. Any suggestions?

❯ echo $PATH
/Users/felixfoertsch/.nodenv/shims:/Users/felixfoertsch/.rbenv/shims:/Users/felixfoertsch/.pyenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin

Edit 3: Okay, I'm an idiot. For grunt to work, there is a cli tool grunt-cli after installing that, I can confirm that the shims DO work.

Main issue still stands with the -g flag.

I have nodenv installed via Homebrew:

brew install nodenv

and In my .zshrc file I have:

eval "$(nodenv init -)"

When I run nodenv --version I get this output:

$ nodenv --version
grep: ../package.json: No such file or directory
nodenv 

Branch with changes is here: https://github.com/jawshooah/nodenv-wiki/tree/nodenv-npm-migrate

I also sorted the plugins alphabetically.

I just read Introducing npx about the new binary npx that comes as part of npm 5.2+ (which comes with node 8). I wanted to use their "Executing one-off commands" example where they do $ npx create-react-app my-cool-new-app where it "installs a temporary create-react-app and calls it".

So I installed node 8. I did nodenv global 8.0.0. I upgraded npm to make sure I had 5.2. I then ran their example:

npx create-react-app real-world-discussions-demo

Output:

nodenv: create-react-app: command not found

The `create-react-app' command exists in these Node versions:
  4.2.3

Oops! I had already installed create-react-app globally in 4.2.3. But wait, I'm not trying to run a global command, right? That's the point of npx. After I deleted create-react-app out of 4.2.3, I ran the command again and it worked as shown in that medium post.

So my question is, why didn't this work as expected? It should have installed a temporary create-react-app in node 8 and called it, but instead it barfed, but that's exactly what npx is trying to prevent. The article mentions that npx should work well with nvm, nave, or n, but doesn't mention nodenv.

Opening this thread to discuss which existing nodenv plugins the nodenv org will take ownership of.

I'm assuming that we just take ownership of any plugins authored by members of the org, but I don't want to make the decision unilaterally.

Hello there, hope you're well 😄

Some time ago, I created a nodeenv-installer which automatically installs nodeenv (similar to rbenv-installer or pyenv-installer).

Since this is a small bash script, I was wondering if you wanted to take over the project and continue it so that you have an easier install method for nodeenv.

Please let me know your thoughts 😄
Fois

New MacBook
Installed Nodenv via Homebrew

npm: command not found

They seem to be ordered by hook path, which makes sense. But then just be in the order of the globbing. Is there a way to control this order, without messing with the hook path?

I git cloned a project that already had a node_version file present, but I didn't have that particular version installed. When I tried to run npm install nodenv showed an error stating the required version was not installed.

Instead of printing an error nodenv should just run nodenv install ... and then run npm install for real.

This would make using nodenv seamless

for example, in ruby:

RUBY_CONFIGURE_OPTS=--with-openssl-dir=/usr/local/opt/openssl rbenv install -s "$ruby_version"

in python:

CFLAGS=-I/usr/local/opt/openssl/include LDFLAGS=-L/usr/local/opt/openssl/lib pyenv install -s "$python_version"

trying to figure out how to do this with nodenv. thanks!

I found one in nodenv 0.4.0 in nodenv --help. A code search shows a couple other places.

The current formula for nodenv in homebrew points to wfarrs variant, not this. I've posted an issue (Homebrew/legacy-homebrew/issues/28955) about which one should be in homebrew but thought I should let you know as well.

I ran into this while migrating from https://github.com/wfarr/nodenv, which expects node versions like v0.8 instead of 0.8. Basically node and the other shims hang if you give a version that doesn't exist without any output:

$ nodenv --version
nodenv 0.0.0
$ NODENV_VERSION=0.8 node --version
v0.8.26
$ NODENV_VERSION=v0.8 node --version















load: 1.71  cmd: bash 72298 running 1.16u 1.18s
load: 1.74  cmd: bash 72298 running 1.63u 1.67s
load: 1.74  cmd: bash 72298 running 1.77u 1.82s
load: 1.74  cmd: bash 74395 running 0.00u 0.00s
load: 1.74  cmd: bash 72298 running 1.92u 1.98s
load: 1.74  cmd: bash 72298 running 2.00u 2.06s
load: 1.74  cmd: bash 72298 running 2.11u 2.17s
load: 1.74  cmd: bash 72298 running 2.19u 2.26s
load: 1.74  cmd: env 72298 running 2.26u 2.33s
^C
$ NODENV_VERSION=trololol node --version



load: 1.68  cmd: bash 75283 running 0.00u 0.00s
load: 1.68  cmd: greadlink 75377 running 0.00u 0.00s
load: 1.68  cmd: bash 75453 running 0.00u 0.00s
load: 1.68  cmd: bash 75572 running 0.00u 0.00s
load: 1.68  cmd: bash 74865 running 0.58u 0.55s
load: 1.78  cmd: bash 74865 running 1.01u 1.00s
load: 1.78  cmd: env 74865 running 1.09u 1.09s
load: 1.78  cmd: bash 74865 running 1.18u 1.18s
load: 1.78  cmd: bash 74865 running 1.31u 1.32s
load: 1.78  cmd: env 74865 running 1.41u 1.42s
load: 1.78  cmd: bash 74865 running 1.50u 1.51s
load: 1.78  cmd: bash 74865 running 1.60u 1.61s
load: 1.78  cmd: greadlink 76818 running 0.00u 0.00s
load: 1.78  cmd: env 74865 running 1.88u 1.91s
load: 1.78  cmd: env 74865 running 1.91u 1.94s
load: 1.78  cmd: greadlink 77066 running 0.00u 0.00s
load: 1.78  cmd: greadlink 77202 waiting 0.00u 0.00s
load: 1.78  cmd: bash 74865 running 2.21u 2.24s
load: 1.78  cmd: bash 74865 running 2.24u 2.27s
load: 1.78  cmd: bash 74865 running 2.27u 2.30s
load: 1.78  cmd: greadlink 77290 running 0.00u 0.00s
load: 1.78  cmd: bash 77309 running 0.00u 0.00s
load: 1.78  cmd: env 74865 running 2.36u 2.39s
load: 1.78  cmd: bash 74865 running 2.39u 2.42s
load: 1.78  cmd: bash 77377 running 0.00u 0.00s
load: 1.78  cmd: bash 74865 running 2.45u 2.48s
load: 1.80  cmd: bash 74865 running 2.47u 2.51s
load: 1.80  cmd: head 77441 running 0.00u 0.00s
load: 1.80  cmd: env 74865 running 2.53u 2.57s
load: 1.80  cmd: env 74865 running 2.56u 2.60s
load: 1.80  cmd: bash 74865 running 2.59u 2.63s
load: 1.80  cmd: bash 74865 running 2.62u 2.66s
load: 1.80  cmd: env 74865 uninterruptible 2.64u 2.68s
load: 1.80  cmd: bash 74865 running 2.65u 2.70s
load: 1.80  cmd: bash 77571 running 0.00u 0.00s
load: 1.80  cmd: bash 74865 running 2.72u 2.76s
load: 1.80  cmd: bash 77606 running 0.00u 0.00s
load: 1.80  cmd: bash 74865 running 2.77u 2.82s
load: 1.80  cmd: env 74865 running 2.80u 2.85s
load: 1.80  cmd: env 74865 running 2.83u 2.88s
load: 1.80  cmd: bash 74865 running 2.86u 2.91s
load: 1.80  cmd: bash 74865 running 2.89u 2.94s
load: 1.80  cmd: greadlink 77732 waiting 0.00u 0.00s
load: 1.80  cmd: bash 74865 running 2.95u 3.00s
load: 1.80  cmd: bash 77772 running 0.00u 0.00s
^C

The blank lines are me holding down return to see if it's responding at all, and the load lines are from holding down control-t which shows the process actively running.

Could you please tag version v0.2.0

thanks

thoughts on a communication channel? I quickly opened a gitter.im room https://gitter.im/nodenv since I figured that would be a lower barrier of entry than a slack group.

also reset the waffle board with the new org: https://waffle.io/nodenv/nodenv The waffle board so far has all the repos that are currently in the org and is a nice way to see all of the issues/prs across the org on one board. It doesn't change anything with github, so no one is forced to use it. Personally, I like being able to see all the repos' issues and prs in one place.

I created a waffle board (https://waffle.io/OiNutter/nodenv) for nodenv/node-build and various plugins. (To get a clear picture of open issues, etc across the ecosystem.)

We need an admin (@OiNutter) to enable webhooks for waffle.io on the repos.

Hi @OiNutter , I've noticed that a newer LTS version(v4.2.4) of node has been released, but it's not available yet from nodenv install -l.

I can't find any doc anywhere that could show me how to add new versions, either in the code. Can you please tell me how to add new versions? Thanks!

Someone have an idea how to added Nod's path for running with sudo?

Woudn't it be nice to have a self-update? I just did it with:

git fetch origin
git reset --hard origin/master

Is there an example for how to use nodenv on Travis CI?
I've tired the setup written in the README.md but that doesn't seem to work, Travis isn't detecting the nodenv binary.

Hi. I love using nodenv. It's great to have the same interface across multiple languages (rbenv, pyenv, etc.).

I wish more people used it.

Can you add a quick "Why choose nodenv over NVM" just like rbenv does in their README?

Thanks!

install command for nodenv lost.

[injectjs@crmtst01 ~/.nodenv]$src/configure && make -C src
make: 进入目录“/home/injectjs/.nodenv/src”
gcc -fPIC     -c -o realpath.o realpath.c
gcc -shared -Wl,-soname,../libexec/nodenv-realpath.dylib  -o ../libexec/nodenv-realpath.dylib realpath.o 

/bin/bash
[injectjs@crmtst01 ~/.nodenv]$echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bash_profile
[injectjs@crmtst01 ~/.nodenv]$export PATH="$HOME/.nodenv/bin:$PATH"
[injectjs@crmtst01 ~/.nodenv]$echo 'eval "$(nodenv init -)"' >> ~/.bash_profile
[injectjs@crmtst01 ~/.nodenv]$eval "$(nodenv init -)"

[injectjs@crmtst01 ~/.nodenv]$type nodenv
nodenv 是函数
nodenv () 
...

[injectjs@crmtst01 ~/.nodenv]$nodenv install
nodenv: no such command `install'

[injectjs@crmtst01 ~/.nodenv]$nodenv 
nodenv 1.0.0
Usage: nodenv <command> [<args>]

Some useful nodenv commands are:
   commands    List all available nodenv commands
   local       Set or show the local application-specific Node version
   global      Set or show the global Node version
   shell       Set or show the shell-specific Node version
   rehash      Rehash nodenv shims (run this after installing executables)
   version     Show the current Node version and its origin
   versions    List all Node versions available to nodenv
   which       Display the full path to an executable
   whence      List all Node versions that contain the given executable

• my server is "Red Hat Enterprise Linux Server release 7.1 (Maipo)"
• install from git zip file nodenv.zip, unzip to nodenv-master, and mv nodenv-master ~/.nodenv

I tried installing nodenv a few diff ways (homebrew, git). No matter what, when running nodenv init, it just sits there forever and does nothing.

Anything I can share to help debug?

System environment: Mac OS X 10.12.5, default bash shell

All nodenv commands stall out the same way. Even nodenv --help

Hi

I have pulled down the latest version on nodenv (15-May-2017) and followed the instructions to install.

When I ran
cd ~/.nodenv && src/configure && make -C src
I got the following error

make: Entering directory '/home/luke/.nodenv/src'
gcc -fPIC     -c -o realpath.o realpath.c  
realpath.c:2:20: fatal error: stdlib.h: No such file or directory  
compilation terminated.  
Makefile:19: recipe for target 'realpath.o' failed  
make: *** [realpath.o] Error 1  
make: Leaving directory '/home/luke/.nodenv/src'`  

As the instructions state that nodenv should still work if this fails I just add nodenv to my path in .bashrc and then run the command
~/.nodenv/bin/nodenv init
The out from that command is as follows

# Load nodenv automatically by appending
# the following to ~/.bashrc:

eval "$(nodenv init -)"`

I added eval "$(nodenv init -)" to the end of my .bashrc file and close all open terminals and opened a new terminal window. when I run the command
type nodenv
I get the result

nodenv is /home/luke/.nodenv/bin/nodenv

If I then run nodenv init I get the same result as before however running
type nodenv
returns

nodenv is hashed (/home/luke/.nodenv/bin/nodenv)

If I manually run
eval "$(nodenv init -)"
and then run
type nodenv
I finally get the expected result and nodenv works as expected

nodenv is a function
nodenv () 
{ 
    local command;
    command="$1";
    if [ "$#" -gt 0 ]; then
        shift;
    fi;
    case "$command" in 
        rehash | shell)
            eval "$(nodenv "sh-$command" "$@")"
        ;;
        *)
            command nodenv "$command" "$@"
        ;;
    esac
}

below are the last three lines of my .bashrc file

export PATH="$HOME/.nodenv/bin:$PATH"
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

Does anyone know what I'm doing wrong? Any help would be appreciated.

Luke

When installing with homebrew, No matter what, I always had to run the eval command on the command line, even after adding it to .bash_profile or .zshrc and resourcing them. Should this go in the docs or was my experience an anomally?

Duplicate of rbenv/rbenv#739 for nodenv discussion

I originally opened that PR against rbenv some time ago to add hooks for version-name and version-origin. Those hooks would expose a point at which plugins could alter the selected ruby version (and its associated origin). The primary use-case for these hooks is for plugins such as rbenv-bundler-ruby-version (wherein the ruby version is selected from a Gemfile instead of .ruby-version). There seems to be some movement on this PR and it appears likely it be included in rbenv 1.0.

Recently, a new nodenv plugin landed nodenv-package-json-engine that does precisely the same thing as rbenv-bundler-ruby-version. (Pulling a node version from package.json engines, instead of .node-version.) The implementations of these plugins are error-prone due to the limitations of rbenv/nodenv. Introducing the hooks I propose will allow the plugins to be implemented in a more robust fashion. (consistent bin resolution with nodenv core; consistency between nodenv-version and nodenv-which)

However, there are other blockers to rbenv 1.0 that I'd rather not wait for. I'd like to see this PR merged into nodenv so that nodenv-package-json-engine can take advantage of the new hooks. (As it stands now, the lack of these hooks is significantly hindering iojs support.)

Are there any concerns about merging this PR to nodenv?

Copy of the original PR description follows:

• version-name hook
  It is invoked after the traditional RBENV_VERSION lookup. Which means hook scripts can interrogate $RBENV_VERSION_FILE and/or $RBENV_VERSION (or use the executables).

  The hooks are then run, giving plugins a chance to alter RBENV_VERSION. Once the hooks have run, we now have (in $RBENV_VERSION) the actual version we want to use (or it's empty which defaults to system per normal). Lastly, the same logic remains for checking if the version exists, or trimming the ruby- prefix.

• version-origin hook

  It is invoked before the traditional rbenv-version-file lookup. Because version-origin is usually run immediately after version-name, then any plugin hooks that alter version-name would have done so. Thus, running version-origin prior to printing the origin gives those plugins a chance to alter the version-origin to match. If any of the hooks set $RBENV_VERSION_ORIGIN, then it is used as the return value. Otherwise, the existing logic continues to return "environment variable" or "filename" as appropriate.

With both of these hooks in place, we have a clean seam by which plugins can inject their own ruby-version-setting logic. Until now, the only mechanism to available to alter the chosen ruby version was in the which hook. Using the which hook is error prone, however, since the hooks must build up the full
RBENV_COMMAND_PATH themselves. Further, with the which hook, commands like rbenv version will report a different ruby than they one that will actually be executed. And functions like __rbenv_ps1 report the wrong ruby version.

Using these new hooks, plugins can safely manipulate the version of ruby chosen, while still leaving the executable-path-lookup to rbenv.

A few plugins that may have some utility being ported to nodenv.

• https://github.com/ianheggie/rbenv-env
  print env vars relevant to node/nodenv/npm
• https://github.com/tpope/rbenv-communal-gems
  share global modules across nodes
• https://github.com/mlafeldt/rbenv-man
  man pages for active node, npm, etc version
• https://github.com/fgrehm/rbenv-install-remote
  install node using custom definition url (like a gist)
• https://github.com/toy/rbenv-update-rubies
  automatically install latest patch (maybe even minor?) versions of each currently installed node
• https://github.com/ianheggie/rbenv-binstubs
  make nodenv aware of local node_modules bins (would resolve #45 )
• https://github.com/rbenv/rbenv-installer
  includes an idempotent installer script, though -doctor is the more relevant one

Any votes on which, if any of these would be most useful for node? Or others?

I stumbled upon this today after upgrading.

When loading fish, the message I'm getting is

setenv: Too many arguments

This is also affecting pyenv and here is their pull request, pyenv/pyenv#927

Copied the title from here which is where I found it, pyenv/pyenv#926
And they also have this pyenv/pyenv#924

I'm having problems installing node using nodenv in a "El Capitan" clean install.

The error I'm getting is curl: (56) SSLRead() return error -9806

Is kinda weird because I'm only getting this error when using nodenv.

I'm pretty sure is related to my environment but I don't know how to get around this error. Any ideas on how to get this working?

Thanks!

When I run nodenv shell I get this error:

$ nodenv shell
nodenv: no such command `shell'

It appears that the command 'shell' is under the wrong path. I found it here, and it appears that since the file is named nodenv-sh-shell rather than nodenv-shell that the nodenv executable can't find it and when I rename it it works properly. Could this file perhaps be named wrong?

Thank you for your time!

wfarr's version of nodenv accepts the v prefix. What do other version managers accept? Do they accept the version specifier both with and without the v prefix? Require it? Require no prefix?

How should we handle this? One possibility is to use https://github.com/jasonkarns/nodenv-aliases to create prefixed symlinks.

Alternatively, we could read in the version specifier and attempt an exact match. If that fails, attempt a match with/without the prefix as a fallback. (This would marginally increase lookup times, but only in the case that the user is using a version spec that doesn't match their builds precisely.)