Name/API

[ljharb]

Hi there - I'm the primary maintainer for creationix/nvm.

If this project is going to have the name "nvm" in it, it would be very helpful if you committed to supporting an identical API and featureset. If not, it would be helpful if you could find an alternative name.

(The nvm-windows project has a similar name but not a similar API/featureset, and it's caused a lot of trouble for maintainers of both projects due to the rampant user confusion)

[felixfbecker]

Thanks @ljharb! This version manager is for PowerShell, and PowerShell has some very strict constraints for how commands and parameters looks like and work. For example, a command always has to look like ApprovedVerb-Noun, e.g. Install-NodeVersion (see Approved Verbs for Windows PowerShell Commands). Parameters always start with -. Output in PowerShell is not text, but objects (that are printed as tables by default). So I don't think the API can or should be shared (besides things like .nvmrc), and everyone in the PowerShell community would understand that. We could define aliases that mimic nvm's commands, but I think that would actually make it more confusing.

Other than that, the feature set is pretty much the same as nvm (much more so than nvm-windows). It installs node versions into a folder and changes PATH like nvm (in opposite to nvm-windows which has a global symlink). It accepts an exact version or semver version range. It is able to read .nvmrc.

I think the readme shows quite well that the API is different and says that ps-nvm is inspired by nvm, but for PowerShell. nvm after all is only an acronym for node version manager, I have trouble coming up with a better name (and this project has existed under this name since Nov 2014).

I do see your concerns though. Do you have specific suggestions how to make the distinction clearer?

[aaronpowell]

Hi @ljharb,

creationix/nvm was very much the inspiration for PowerShell nvm when I started it back in 2014 (essentially filling the gap of there being no Windows nvm, or at least not one that's designed for PowerShell).

Over that time I've tried to keep the spirit of nvm alive in the feature set of PowerShell nvm, but doing it in a PowerShell design. That's why I added support for things like .nvmrc support.

@felixfbecker covers off all the technical differences nicely and because of that I think we've got a clear separation in how we work compared to your tool, but we're open to looking at how best to make the distinction between the tools clear.

[ljharb]

I wish I'd known sooner :-) nvm-sh/nvm#1682 seems a few years late ;-)

I'm certainly not entitled to, nor intending to, make any demands :-) However, my experience is that either changing the name so it doesn't include "nvm", or ensuring that the featuresets are as similar as possible, helps avoid problems.

If PowerShell has requirements that its users all understand, then that does suggest there won't be an issue there. I would expect - and hope - that everything listed in nvm --help is also available in ps-nvm, even if the exact command API is slightly different. Is that the case?

[aaronpowell]

Hehe that's on me, over the years I've thought "I should submit a PR to nvm to get listed as Windows support" and then something shiny catches my attention and I forget about it 😛.

By and large I think we've got everything nvm has, things I know we don't have are:

• iojs support (I removed that a few minor versions ago)
• lts alias support
• custom aliasing (adding that would make lts easier)

Alias support i'm happy to add, but I don't see any value in having iojs support so I wouldn't be adding that back in.

[ljharb]

1. The value of having iojs support is the same as having support for older versions of node
2. Having iojs support will dovetail into nvm's eventual addition of RC and Nightly support, as well as eventual support for node built with alternative JS engines.

I'd say custom + LTS + built-in aliasing would be great to add, because then (modulo iojs support) the featureset is indeed equivalent.

[aaronpowell]

The iojs support was a little different (here's the removal commit: aa4a653), basically I had cmdlets like Install-iojsVersion, Set-iojsVersion, etc. rather than running it through the Node functions like we do for installing older versions of node.

[ljharb]

Would you be willing to re-add it if it was just v1-v3 of node?

[aaronpowell]

Hmm possibly, depends how I go about doing alternative engine support. Is there much usage of installing io.js?

[ljharb]

Probably not a ton; all of my packages test on every minor version of node, including io.js, but I'm probably in the minority. It's more about making it possible for packages that support older platform versions to do that testing.