jasongin / nvs Goto Github PK

NVS caches downloaded archives (node*.7z, node*.tar.xz, etc.) at $NVS_HOME/cache. Currently these files remain in the cache indefinitely even after removing an installation via nvs rm.

Maybe the archives should also be removed by nvs rm. Or maybe there should be commands for managing the cache: nvs cache ls, nvs cache rm, nvs cache clear.

I would be happy to see the NVS in Chocolatey for automatic installation on the new machine(s).

Documentation: https://chocolatey.org/docs/create-packages

Hey @jasongin,

I'm very excited about nvs! Hope you can help me out with my issue:
I want to use the nvs command in git hooks (e.g. a pre-commit hook) to run npm tests with the correct node version as specified in the project settings (.node-version).

But when I try to call nvs inside the pre-commit script I get a nvs: command not found.

In my .bashrc file I added the two following lines:

export NVS_HOME="$HOME/.nvs"
[ -s "$NVS_HOME/nvs.sh" ] && . "$NVS_HOME/nvs.sh"

How can I have nvs accessible in my git hooks?
Any ideas?

I'm really enjoying using NVS! One thing that would be a nice addition would be the ability to migrate global NPM packages from one Node version to another, particularly as part of the process of adding a new one (e.g. nvs add 7 --reinstall-packages or something). I got used to this feature when using NVM, and it's pretty handy when updating Node fairly regularly.

If I'm running a version of Node, and I run nvs rm on it, my initial expectation was that NVS would actually switch me back to my default version (if one was set). That way if I'm experimenting with something in a nightly build (for example), and then I want to clean it off my system after I'm done, I don't need to run nvs rm and then nvs use default in order to get back to my default state.

This is pretty low-priority behavior, and I suppose it's actually somewhat subjective whether it's the right thing to do, but I thought I'd log it as a conversation point :)

I really like how the lsr command allows filtering the results by version range (e.g. 4, 6.9). Since the results also display the LTS release name next to relevant versions (e.g. Argon, Boron), it would be cool if you could use that string as a filter in order to see just versions which are a part of a specific LTS release. For example, that would allow users to easily check if there are any new updates for the Node v6 LTS release, without needing to remember that it corresponds to v6.9.* (e.g. nvs lsr node Boron). This can be pretty easily achieved via nvs lsr node | grep Boron, so this is more of a "fit-n-finish" request, that I'm not sure whether other users would find that valuable.

I tried to install nvs on macOS Sierra 10.12.3 with zsh 5.3.1, following your instruction:

Mac, Linux

Specify the installation path, clone the repo, and source the install command:

export NVS_HOME="$HOME/.nvs"
git clone https://github.com/jasongin/nvs "$NVS_HOME"
. "$NVS_HOME/nvs.sh" install

After I sourced the install command, I encountered this issue:

Downloading bootstrap node from https://nodejs.org/dist/v6.9.4/node-v6.9.4-darwin-x64.tar.xz
nvs:39: no matches found: -#
mv: rename /Users/foo/.nvs/cache/node-v6.9.4-darwin-x64/bin/node to /Users/foo/.nvs/cache/node: No such file or directory
rm: /Users/foo/.nvs/cache/node-v6.9.4-darwin-x64: No such file or directory
Failed to download boostrap node binary.

NVS downloads node, but forgets to unpack it.
If you unpack it manually and restart installation, then it finishes successfully.

I really like the refactoring you did to the remote command in v0.8, which exposes it as a command sub group. It would be great to make the same change to the alias command (e.g. by adding nvs alias add, etc.), for both consistency, but also to accomodate users that would find that interface more intuitive (including me!).

Running any nvs commands would fail with:

ConvertFrom-Json : Invalid object passed in, ':' or '}' expected. (1): {
At C:\ProgramData\nvs\nvs.ps1:35 char:67
+     $bootstrapNodeVersion = ((Get-Content $scriptDir\defaults.json |
ConvertFrom-Js ...
+
~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-Json], ArgumentEx
   ception
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Co
   mmands.ConvertFromJsonCommand

ConvertFrom-Json : Invalid object passed in, ':' or '}' expected. (1): {
At C:\ProgramData\nvs\nvs.ps1:36 char:66
+     $bootstrapNodeRemote = ((Get-Content $scriptDir\defaults.json |
ConvertFrom-Jso ...
+
~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-Json], ArgumentEx
   ception
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Co
   mmands.ConvertFromJsonCommand

ConvertFrom-Json : Invalid object passed in, ':' or '}' expected. (1): {
At C:\ProgramData\nvs\nvs.ps1:37 char:66
+     $bootstrapNodeBaseUri = (Get-Content $scriptDir\defaults.json |
ConvertFrom-Jso ...
+
~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-Json], ArgumentEx
   ception
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Co
   mmands.ConvertFromJsonCommand

Downloading boostrap node from v/node-v-win-x64.7z
Invoke-WebRequest : The remote name could not be resolved: 'v'
At line:1 char:44
+  $ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -Uri
'v/node-v-win- ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:Htt
   pWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe
   ll.Commands.InvokeWebRequestCommand


ERROR: The system cannot find the file specified.
C:\ProgramData\nvs\cache\node-v-win-x64.7z



System ERROR:
The system cannot find the file specified.

C:\ProgramData\nvs\nvs.ps1 : Failed to download bootstrap node binary.
At line:1 char:1
+ C:\ProgramData\nvs\nvs.ps1 bootstrap
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep
   tion
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio
   n,nvs.ps1

I have attempted to drill down to the root cause, and it seems like PowerShell on this version of Windows has a more restrictive ConvertFrom-Json:

bad.json

{
  "bootstrap":"node/6.10.1"
}

PS C:\> Get-Content .\bad.json | ConvertFrom-Json
ConvertFrom-Json : Invalid object passed in, ':' or '}' expected. (1): {
At line:1 char:26
+ Get-Content .\bad.json | ConvertFrom-Json
+                          ~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-Json], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.ConvertFromJsonCommand

good.json

{"bootstrap":"node/6.10.1"}

PS C:\> Get-Content .\good.json | ConvertFrom-Json

bootstrap
---------
node/6.10.1

Windows 10's PowerShell works fine in both cases.

Hi,

I did not install node using the installer from nodejs website instead, I directly downloaded and installed nvs and using it, I installed nodejs and nodejs-chakra.
However, after setting a version to use it is not setting permanently updating the PATH. Meaning its using "set" instead of "setx". And sets the path only for that instance of the cmd.
So every time I open a cmd I have to select the version I want and then I have to start to work. So why not set it permanently and also permanently change everytime I nvs use a version?

Hi @jasongin ,

Actually, I have a problem to add a node.js version. Here my error:

nvs add v7
Failed to download index: https://nodejs.org/dist/index.json
getaddrinfo EAI_AGAIN nodejs.org:443

I think the problem is the proxy settings. But I didn't seen a proxy configuration in your documentation.
I already configured the "proxy", "http_proxy" env but I doesn't work.

Have you an idea ?

Thanks for your work ;)
See you

This feature is under development in the auto branch. Currently it is working pretty well for PowerShell. If anyone would like to preview this feature and provide early feedback, checkout that branch and read details here: https://github.com/jasongin/nvs/blob/auto/doc/AUTO.md

I still need to do some more testing, and implement equivalent functionality for POSIX, probably using the same mechanism as nodengine.

The best part of this feature won't be available to Windows Command Prompt users, since there is no way there (AFAIK) to hook into directory changes. However they can still manually run nvs auto at any time to trigger the same search for per-directory config.

I downloaded and installed nvs 1.0.1 on a Windows 10 1607 VM running in VirtualBox. When I attempt to run nvs I get the following error:

C:\Users\kfarnung>nvs
Cannot read property 'startsWith' of undefined

I believe previously this would bring up the interactive menu. I still seem to be able to use the command-line options to switch versions.

I'm attempting to use NVS to maintain node on an RP2 but when I attempt to install any version of node I get "Platform package not available for version: node//arm". Is this supposed to work, or is this an expected error?

1. Platform-specific scripts that automatically fetches the most recent lts version and does the installation (mostly *shell scripts)
2. User-invoked nvs command scripts for version management

To take it even further: we could have a node version management "stack" with layers for installation shell scripts, node management command scripts, and a possible GUI layer.

Hello,

I've attempted to install nvs using the commands from README.md, but the installation fails with the following error.

Like mentioned in the title, my environment is macOS 10.12.2 with zsh 5.2 (shipped with the OS.)

$ export NVS_HOME="$HOME/.nvs"
git clone https://github.com/jasongin/nvs "$NVS_HOME"
. "$NVS_HOME/nvs.sh" install

Cloning into '/Users/oliver/.nvs'...
remote: Counting objects: 904, done.
remote: Total 904 (delta 0), reused 0 (delta 0), pack-reused 904
Receiving objects: 100% (904/904), 548.89 KiB | 0 bytes/s, done.
Resolving deltas: 100% (634/634), done.
nvs:29: = not found

From discussion at #5

Currently 7zr.exe is checked in to the NVS repo. It is used to extract .7z archives on Windows, to allow for smaller downloads and faster extraction compared to using ordinary .zip archives.

While it's only 444 KB, putting binaries in git is a bad practice. Instead, NVS could download 7zr.exe before it is needed. Of course that would only be for Windows. (On other platforms NVS uses tar's .tar.xz extraction support if available, otherwise it falls back to .tar.gz archives.)

Currently the only official way to download 7zr.exe is as part of the LZMA SDK. This change for NVS would require 7zr.exe to be posted separately somewhere.

Windows 10: Instead of Program Files, I put Node in C:\Node. This was before installing NVS. If I run nvs ls, it doesn't list my pre-installed Node (it only lists the ChakraCore install that I actually used NVS to perform...)

I didn't see a relevant command in the docs – sorry if I missed it.

It would be great if all commands which accepted a version flag allowed you to omit the minor and patch components, as long as NVS could resolve the correct version in an unambiguous way. For example, I'd love to be able to run nvs use 6 and have it detect that I only have a single 6.* (e.g. 6.9.1) version installed, and switch to it automatically. That way, I can have a 4., 6. and 7.* release installed at the same time, and switch between them without needing to remember the exact version.

When adding a version, users commonly want to use it immediately, and/or migrate global modules from some existing version to the added version. So it might be convenient if a command syntax something like the following was supported:

nvs add 6.9.1 --use --migrate 6.8.0

That would be just a little shorter than the currently-supported equivalent:

nvs add 6.9.1; nvs use 6.9.1; nvs migrate 6.8.0

Since it's not really a huge difference, I think this is a fairly low priority feature. And personally I sort of prefer to keep the commands simple and discrete... but I'm open to feedback on this.

It would be nice to somehow keep track of Node.js versions installed using version labels (not version numbers) to be able to upgrade them using a single command.

For instance, if I installed several Node.js versions using version labels: nvs add argon, nvs add boron, nvs add latest and nvs add nightly, I would be able to upgrade all version labeled versions using nvs up / nvs upgrade to the latest version of argon, boron, latest and nightly.

I upgraded to NVS v0.8.0, added the latest Node version (7.2.0), and when I tried to migrate my current global NPM packages to it via nvs migrate 7.1.0, I got the following error:

Am I doing anything wrong? The migrate command has worked great up to this point, so maybe something regressed in the latest version? I'm running macOS Sierra, in case the issue is OS-specific. Thanks!

Actual (current): invalidates the node & npm commands in my current shell.

Is this desired? Should nvs select the default node version if it exists?

Also what if the user removes the default node version?

I tried to install nvs 1.1.3 but the installation hung with while the message was something with publish. To reproduce or install an older version, I tried to deinstall version 1.1.3 but this hangs also while "Please wait while Windows configures NVS". OS: Window 7

When I tried nvs rm with multiple version numbers it only removed the first one and ignored the rest.

It would be better for nvs rm to show an error message in this case.

It would be even better for nvs rm to support multiple version numbers.

As a general note I would like to thanks @jasongin again for such nice work. I am really happy to have it all work the same way on macOS & Windows and have abandoned the other Node version managers.

This is based on the observation that nvs add lts works but nvs use lts doesn't. It would be nice if nvs add would automagically create an alias of that label.

I have a question regarding how labels are used with the use command.

The docs state that a version must already have been added with add before the use command can be used. Which implies that use works entirely offline. Is this correct? Which means a label (such as latest or lts) will only refer to the latest node on the user's machine?

Scenario:

1. User installs latest lts: nvs add lts (which, for this scenario, let's say is 6.0.0)
2. User does some work and switches to another node: nvs use 5.0
3. A new v6 is released (let's say, 6.1.0) so latest lts is now 6.1.0
4. User wants to switch back to lts: nvs use lts

What happens for step 4? Does it just activate the "latest" lts they have locally available (6.0)? Or does it check online, know that 6.1 is latest lts, and emit an error or warning? Since 6.1 hasn't been added, I presume that it won't automatically download 6.1.

I'm assuming it does the former. Which means there's just a disconnect between how the labels work for add vs use (not so much a disconnect, as a wrinkle to be aware of).

I'm one of the maintainers of nodenv and would love to chat sometime about some of the more edge-case scenarios; if you'd be willing.

Hi, just as in the title, since I cant find anything about that in the readme-
is NVS setting any env vars- mostly is it setting up a global NODE_PATH for npm?

and thank you for making nvs, I like your solution a lot.

In case I am too lazy to actually type the default node version id.

I run nvs link default 7.9.0 and nothing happens. If I open a new cmd shell I still see node -v giving me 6.10.0

This is on windows 10.

I'm trying to set the system default version of node to 7.9.0

I'm working on this, initially covering AppVeyor and Travis CI specifically. The goal is make it easy to set up your CI to use any Node version (or matrix of versions) that can be installed by NVS.

Something that might be a little unintuitive is that you have to cd into a directory where a version requirement is set before that becomes active.

E.g.

$ echo "v6.0.0" > .node-version
$ cd ..
$ node app/index.js

The node version might not be 6.0.0, even though the directory setting says it should be. I know this is an edge case, but something one should be aware of imo ;)

Hello, @jasongin,

Firstly, thanks for nvs. This project looks a lot nicer than nvm-windows.

Unfortunately, I have a problem with the nvs link command. I'm use cmd from ConEmu.

$ ver & nvs -v & node -v & npm -v
Microsoft Windows [Version 10.0.14393]
0.8.3
v7.3.0
3.10.10

$ nvs ls
 >node/7.3.0/x64
  chakracore/7.0.0-pre10/x64

$ nvs link 7.3.0
Cannot read property 'split' of null

Data from my system and console.log 😄 in link.js:

function linkToWindowsProfilePath(link, linkPath, isSystem) {
  link: true
  linkPath: C:\Users\Denis\AppData\Local\nvs\default
  isSystem: false

  profilePath: null
}

function getEnvironmentVariable(name, isSystem) {
  regKey: HKCU\Environment
  regLabel: user
  regValueType: REG_EXPAND_SZ

  child.stdout.toString(): ����� �����襭: ������� ᮢ�������: 0.
}

It seems to me that the problem is that I use Windows with Russian language Package.

If I run the command manually, I get:

$ reg.exe QUERY HKCU\Environment /V PATH /T REG_EXPAND_SZ
Поиск завершен: найдено совпадений: 0. // Translate: Search is finished: found matches: 0

If I run the command manually without name:

$ reg.exe QUERY HKCU\Environment /V PATH

HKEY_CURRENT_USER\Environment
    PATH    REG_SZ    C:\Users\Denis\AppData\Roaming\nvm;C:\Program Files\nodejs;C:\Program Files (x86)\Microsoft VS Code\bin;C:\Users\Denis\AppData\Local\Microsoft\WindowsApps;C:\Program Files\nodejs;C:\Users\Denis\AppData\Local\atom\bin;C:\Users\Denis\AppData\Local\nvs\

Works fine if I set:

// ----------------\/ negative
let regValueType = (!/path/i.test(name) ? 'REG_EXPAND_SZ' : 'REG_SZ');

Let me know if I can help you 🌮

see yargs/yargs#811

any suggestion?

In order to update the NVS bits I have installed, I've currently been cd'ing into the $NVS_HOME directory and then running a git pull. This is pretty simple, but it would be nice if either NVS was distributed via package managers (e.g. Homebrew), which would allow easy platform-native updating, or if it had a command for updating itself (like Yarn has). Either one would be cool, and would help simplify keeping up-to-date with the project.

As a nit I would really love to see another solution than the following hard-coded dependencies:

• 7-Zip for Windows
• Node 6.8
• node_modules/progress

I think it should be possible to use a prepublish script to keep the 7-Zip and progress dependencies out of the project.

I can think of the following possible alternatives to "Node 6.8":

• minimal node build that leaves out some things such as HTTPS server support, to avoid "insecure" programs hanging around longer than necessary
• something simpler like Duktape, perhaps with "dukluv" to get an API similar to Node.js

Ideal would be to use git rebase and force push to remove 7zr.exe (7-Zip) from the git history. I think it should be relatively safe to do this now if you post a clear notice for the existing nvs hackers.

In general I am extremely happy with this package. Having recently moved from n to nvm I moved to nvs also on my Windows system and got rid of nvm.

I live in my shell and generally speaking the only interactive command I run is vim (either directly or via git commit/git rebase -i) and it is kind of annoying that running nvs without any arguments drops me in to an interactive session instead of just printing out a usage statement.

I realize it is probably my UNIX-beard screaming and that the majority of the target audience probably like this interactive mode, it would make me so very happy if there was an env var something I could set to change the default mode to match nvs help.

It would be helpful if the version list displayed by the lsr command had some kind of visual cue to indicate if any versions are already installed or if a version represents the currently running version. This way, I could run lsr and see if there is a newer version that what I've already installed/running, without needing to remember exactly which versions I have. This would just provide a shortcut for running ls and comparing the lists, but I like how the ls command already provides indication of running and default versions, and it would be cool if the lsr command provided similar context to better help read the data.

It appears that the changes in d9f82ec to add support for git bash on Windows inadvertantly broke bash support on macOS (and I suspect Linux).

It appears to turn all POSIX paths to Windows paths, which results in a new directory in $NVM_HOME that is the fully expanded version of itself with the slashes reversed.

I really like how the nvs add and nvs use commands support the latest version alias in order to install and switch to the latest version that is available within a specific remote. However, I noticed that neither the ls nor lsr commands support the same capability. I would like to be able to quickly check what the latest available version is within a specific remote (e.g. nvs lsr node/latest or even nvs lsr latest to use my default remote), however, when I try that, the command simply outputs no value, but also, doesn't print an error.

Since the nvs lsr command supports the lts alias to find all lts versions, it seems reasonable for it to also support the same special latest value that other commands do, for the use case that I mentioned above. Since the lsr command will also indicate installed/current status of each version it lists, if you were to run nvs lsr latest, you could quickly see what the latest version is, as well as if you already have it and/or are already running it.

Supporting nvs ls latest is less valuable (at least to me now), but adding it would be ideal in order to be consistent across commands, which I think is important for the ergonomics/fluidity of the NVS CLI.

The nvs rm command doesn't seem to allow omitting the patch component in the specified version argument. However, if you use it this way, it actually prints an output string which makes it appear to have worked, even though it didn't. The following image illustrates the behavior of the add, ls and use commands, and the inconsistent behavior of the rm command:

Additionally, I can confirm that the same behavior happens if you provide just a major component (e.g. 7 instead of 7.1). All of the other commands work as expected, however, the rm command doesn't.

As soon as I specify the full version string (e.g. 7.1.0), then the nvs rm command works as expected. However, the output that is provides in this case is the exact same as with the major and major/minor attempts, so from the end-users perspective, it's not possible that actually determine if it worked, aside from running nvs ls to see if it's still installed.

It's not immediately obvious how to exit from the nvs menu. My instinct was to hit q but that did nothing. I think newer macbooks don't have escape either- it would be nice if nvs supported both q and escape to quit the menu

Given:

$ nvs ls
 >node/7.7.3/x64
  chakracore-nightly/8.0.0-nightly2017031520fa6b1909/x64

I would expect nvs use chakra to match chakracore-nightly/8.0.0-nightly2017031520fa6b1909/x64.

There appears to already be support for segment matching, so nvs use chakracore-nightly and nvs use node select the obvious nodes.

I haven't looked at the code yet to see if this would be ugly to implement or not, just something I found myself wanting while experimenting moving from nvm on my Mac.

.-----------------------------.
| Select a chakracore version |
+-----------------------------+
|  a) chakracore/7.0.0-pre9   |
|  b) chakracore/7.0.0-pre8   |
| [c] chakracore/7.0.0-pre10  |
|  d) chakracore/6.0.0-pre7   |
|  e) chakracore/6.0.0-pre6   |
|  f) chakracore/6.0.0-pre5   |
|  g) chakracore/6.0.0-pre4   |
|  h) chakracore/6.0.0-pre3   |
|  i) chakracore/6.0.0-pre2   |
|  j) chakracore/6.0.0-pre1   |
'-----------------------------'

In the above, 7.0.0-pre10 should be at the top of the list. It behaved the correct way in 0.9.1.

Repro:

1. Get head.exe from your favorite win32 unix tools port (eg. https://sourceforge.net/projects/unxutils/)
2. Run nvs lsr nightly | head

Result:

  nightly/8.0.0-nightly201701234757ddcce1
  nightly/8.0.0-nightly20170122ff75e21662
  nightly/8.0.0-nightly2017012193c4820458
  nightly/8.0.0-nightly201701247eef09ddcf
  nightly/8.0.0-nightly2017011949902124a9
  nightly/8.0.0-nightly20170118622b43997f
  nightly/8.0.0-nightly20170117d86ff5fc29
  nightly/8.0.0-nightly20170116a0e13dae1f
  nightly/8.0.0-nightly2017011534bf31ea8a
(node:68616) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: write EOF

Hey,
requiring to migrate (essentially copy?) global modules for every version seems like overkill to me.
I believe (correct me if this is not the case) that the node native API is compatible across all versions within a major version, so if that's the case would it make sense to have global modules per major version? I think this would be a big UX improvement.
But overall I really like your work so far. Great stuff!