nvm use alone with .nvmrc always returns "Invalid version."

[almic]

Disclaimer: This is more of a feature request, however due to the nature of nvm being heavily associated with it's linux implementation, I think it is more appropriate to call it a bug when differences like this exist on what should be (and many reference guides assume to be) a 1:1 platform port.

Issue:
According to the nvm documentation for Linux, standard behavior of nvm use without arguments is to use the version specified in the .nvmrc file of the current directory, or earliest parent directory. It seems the behavior is different on windows. Unfortunately all online guides I could find are written for the linux version, and treat the two OS implementations the same. Hence, my initial confusion, and creation of this issue upon finding this repo.

How To Reproduce:

1. Create .nvmrc file with contents 6.16.0
2. Open command prompt in the directory and run nvm use
3. Output says "Invalid version."
4. Run nvm use 6.10.0
5. Output says "Now using node v6.16.0 (64-bit)"

Expected Behavior:
nvm use with no arguments would use the version in the nearest .nvmrc file

Desktop:

• OS: Windows 10

Additional context:
I went a little crazy before realizing the doc I was referencing was for the unix versions, and I use the windows version which has a bit different behavior. I wish it wasn't so that online guides seem to neglect making it clear when offering the windows alternative that it's a completely different thing with different behaviors. Every online guide I found about using multiple node versions uses the nvm use command and never mentions that such use is unsupported by the windows versions. Unfortunately they assume the two are identical in every way, only offering small "download for Windows" links, and never indicate that differences exist.

I found the issue #318 and it seems that running the command this way now defaults to always returning Invalid version. Also it seems you stated that this usage isn't supported in #16, which is quite a long issue and wasn't necessarily about this usage except after some long discussion. Besides that relatively buried comment, there's nothing I could find specifically detailing this difference between the two, or specifically saying that this usage will never be supported. I don't really want to be using a batch script just to simulate this usage of the command when those scripts are so short they may as well just be added to the command.

tl;dr: You never explained why this usage is unsupported, so I'm taking it as a "not yet supported." I was hoping the windows implementation of nvm could be unified with the unix version here, or perhaps some better indication in the documentation here that the unix usage of the command isn't supported and an argument is always required. Maybe some section of "Differences from linux?"

[almic]

Just to reiterate, I know that the .nvmrc file is unsupported here. My point is that it makes no sense why it should be unsupported, that no guides I can find exist which explain that nvmrc is unsupported on Windows, and that the error message is unclear that a version argument is required. "Invalid version," as I took it, seemed to mean "I read that file and it didn't have a valid version," rather than the real cause which was no version argument was passed.

[coreybutler]

First, I understand your confusion. This has been a long-standing problem. Unfortunately, I can't police the blogs/guides to assure they're accurate. There's a lot of bad/incomplete content on the web.

The main answer to your question is described at the top of the README:

Many people believe this is just a copy of nvm, but it never has been. The philosophy differs.

I receive a lot of questions about why certain nvm features aren't included in nvm. Some of these are buried in comment threads, so I took some time to summarize in the wiki "common issues" section.

[almic]

i appreciate you giving your reasoning, despite the naming choice being inherently confusing and the many people who want this feature and genuinely do not know why you insist on rejecting it given the popularity of both repos.

may you please adjust the error to say "A version argument is required" at the least?

[coreybutler]

People request features all the time without understanding the development/maintenance consequences. The desires are heard, but the resources to support some efforts simply aren't there. That's why I'm working on rt, NVM4W's commercial open source successor. More resources (time & money) = more features and support. I would have considered nvmrc support earlier in the life of the project if someone had considered sponsoring the work. At this point, new NVM4W features create a bottleneck for rt progress.

When new features are requested, I debate whether they are a version management concern or an environment management concern. If it's a version management maintenance concern, I fit it into NVM4W if time allows. Everything else goes in the rt backlog for review and/or implementation.

A different error message does seem like it may curb some confusion for those coming from nvm. I'll reopen this to make sure that is in an upcoming maintenance release.

[0liver]

@coreybutler I'm very fond of the time and effort you're putting into this project, and again, into this thread. It motivated me to create a PR for the request by @almic: #731.

I hope this helps.

[coreybutler]

Thanks @0liver, that helps! I'll make sure it makes it gets merged into the next maintenance release.

[keithpickering]

Just popping in here to say it makes no sense to call your thing "NVM" and then say it's totally different from NVM. It feels almost deliberately confusing for people who just need to get a project set up

[coreybutler]

It's not totally different, @keithpickering. It serves the same goals. The projects used to be more aligned, but diverged over time. At some point along the way (after NVM4W was launched), nvm started becoming more of an environment management tool rather than just managing which versions of Node were installed on a computer.

The Node version management working group was setup to identify standards, but it became clear that each project had its own notions of how things should be done. The group never arrived at a consensus. By that time though, renaming this project would have even deeper consequences for the community.