Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"$ nvm install 5" does unexpected thing #156

Closed
1 of 17 tasks
ORESoftware opened this issue Mar 16, 2016 · 18 comments
Closed
1 of 17 tasks

"$ nvm install 5" does unexpected thing #156

ORESoftware opened this issue Mar 16, 2016 · 18 comments
Projects
Milestone

Comments

@ORESoftware
Copy link

ORESoftware commented Mar 16, 2016

My Environment

  • Windows 7 or below (not truly supported due to EOL)
  • Windows 8
  • Windows 8.1
  • Windows 10
  • Windows 10 IoT Core
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • My Windows installation is non-English.

I have already...

  • read the README to be aware of npm gotchas & antivirus issues.
  • reviewed the wiki to make sure my issue hasn't already been resolved.
  • verified I'm using an account with administrative privileges.
  • searched the issues (open and closed) to make sure this isn't a duplicate.
  • made sure this isn't a question about how to use NVM for Windows, since gitter is used for questions and comments.

My issue is related to (check only those which apply):

  • settings.txt
  • proxy support
  • 32 or 64 bit support

Expected Behavior

nvm install 5

would install latest version (whatever it was)

Actual Behavior


C:\Users\denman\WebstormProjects\suman>nvm install 5
panic: runtime error: index out of range

goroutine 1 [running]:
/C/Users/Corey/Documents/workspace/nvm-windows/src/nvm/web.IsNode64bitAvailable(0x12226134, 0x1, 0x674700)
C:/Users/Corey/Documents/workspace/nvm-windows/src/nvm/web/web.go:153 +0x157
main.install(0x12226134, 0x1, 0x674700, 0x2)
C:/Users/Corey/Documents/workspace/nvm-windows/src/nvm.go:171 +0x484
main.main()
C:/Users/Corey/Documents/workspace/nvm-windows/src/nvm.go:65 +0x64e

Steps to reproduce the problem:

just run

$ nvm install 5

thanks, this is working for me so far! just wanted to let you know that I expected that command to work. Cheers!

@ORESoftware ORESoftware changed the title $ nvm install 5 does unexpected thing "$ nvm install 5" does unexpected thing Mar 16, 2016
@coreybutler
Copy link
Owner

Thanks for the feedback. While this isn't a bug, I appreciate knowing this is the behavior you were expecting. I've marked it as an enhancement request.

@ORESoftware
Copy link
Author

np, sounds good!

@KoteKotlyarov
Copy link

Looks like we must to tell nvm exact version we want it to install. nvm install 4 will fail with similar errors, but nvm install 4.4.4 will install 4.4.4 version of node...

Why not tell it in Error like unknown version or smth else...

@jamestalmage
Copy link

This is actually more important than facilitating convenience. It is needed on CI servers to ensure the latest version is installed. Otherwise I must update our CI configuration every time Node releases a patch.

@coreybutler
Copy link
Owner

@jamestalmage - So support for nvm install latest has been around for awhile.

I just released a new version. I don't think it behaves exactly as desired, but it won't error out on something like nvm install 6. Instead, it fills in the minor and patch versions automatically. So, nvm install 6 would install version 6.0.0.

Since this doesn't address the enhancement request in it's entirety, I'm going to leave this open.

@insin
Copy link

insin commented Jul 26, 2016

Can this feature request also cover nvm use?

That's the command I use the most and it'd be much more convenient to do nvm use 4 to use latest 4.x version I have installed, rather than having to nvm list first to check.

@coreybutler
Copy link
Owner

@insin - Yeah, nvm use should pretty much always mirror nvm install syntax. When I get around to implementing this, it should be in both.

@jedwards1211
Copy link

@coreybutler if I remember correctly, UNIX nvm install 6 installs the latest version of Node 6, not 6.0.0. That caught me off guard.

@sandman21dan
Copy link

Some other aliases would also be useful, like unix nvm or node's oficial docker image

nvm install lts -> installs latests lts version
nvm install boron -> installs latest boron version
And as stated before
nvm install 6 -> installs ^6.x.x semver style

@robertmain
Copy link

robertmain commented May 31, 2017

I'm gonna sort of weigh in here(I hope this is the right place for it) and say that I tried to do nvm install 8 which got me:

goroutine 1 [running]:
_/C_/Users/Corey/Documents/workspace/nvm-windows/src/nvm/web.IsNode64bitAvailable(0x1104a0dc, 0x1,     0x674700)
        C:/Users/Corey/Documents/workspace/nvm-windows/src/nvm/web/web.go:153 +0x157
main.install(0x1104a0dc, 0x1, 0x674700, 0x2)
        C:/Users/Corey/Documents/workspace/nvm-windows/src/nvm.go:171 +0x484
main.main()
        C:/Users/Corey/Documents/workspace/nvm-windows/src/nvm.go:65 +0x64e

The paths there referring to Corey look like they might be hard coded somewhere?

@coreybutler coreybutler modified the milestone: 2.0.0 Jul 15, 2017
@coreybutler coreybutler added this to Backlog in 2.0.0 Jul 15, 2017
@stephenmichaelf
Copy link

According to this @jedwards1211 is correct. Is there any way we can get feature parity with the Linux/Mac version? We want to use nvm for builds across platforms and are unable to due to inconsistencies in nvm.

@coreybutler
Copy link
Owner

@stephenmichaelf This particular feature will likely be in parity with nvm in an upcoming release, but there are different philosophies about version management. NVM4W is more in line with n than nvm, so there probably won't be feature parity.

FWIW, NVM4W will be going through a naming change when I get the next major release done, primarily because it will work on all operating systems. I don't know when that will be right now (I have 7 client projects right now... and I'm hiring for anyone reading this)... but I have alot of work complete (been running it on my mac for several months).

@Mart-Bogdan
Copy link

Hello @coreybutler, any hope it would be fixed?
I've already created fresh issue #596 which describes current behavior, and some code research from @Serializator .

The current issue seems reporting the crash, but the current behavior is to just download x.0.0 for x >9 and pick the latest minor ver for x <10

@Mart-Bogdan
Copy link

Ok, I see there are also two issues for mvn use

Hmm, I'm wondering is that the same code path? I think not, nvm use should consider only locally insntalled ones

motiz88 added a commit to motiz88/react-native that referenced this issue Jun 4, 2021
Summary:
Pull Request resolved: facebook#31656

CircleCI's Windows executor currently ships with a pre-LTS release of Node v12, breaking our Windows jobs ([example](https://app.circleci.com/pipelines/github/facebook/react-native/9280/workflows/21e6e59c-d853-47a1-af62-1368c8ce10ce/jobs/203983)) following facebook#30637, ultimately due to jestjs/jest#10685 dropping support for non-LTS versions in the Node v12 release line.

Luckily, the Windows executor [does ship with nvm](circleci/circleci-docs#3733) so we can use that to install a desired Node version. Rather than just pinning a later v12 release that is LTS, we pin a v14 release that is currently the most recent LTS version.

NOTE: The nvm on CircleCI is https://github.com/coreybutler/nvm-windows, not https://github.com/nvm-sh/nvm, and the two aren't interchangeable. [nvm-windows has no functionality to install the latest version of a release line](coreybutler/nvm-windows#156) so we're forced to specify an exact version, which will need to be bumped manually in the future. This isn't great, but IMO it's no worse than the current situation, where we use whichever stale version of Node happens to be bundled with the Windows CircleCI executor.

Changelog:
[Internal]

Differential Revision: D28896581

fbshipit-source-id: abf3b56a256f89374add1c01ae6b99a8ba234112
facebook-github-bot pushed a commit to facebook/react-native that referenced this issue Jun 4, 2021
Summary:
Pull Request resolved: #31656

CircleCI's Windows executor currently ships with a pre-LTS release of Node v12, breaking our Windows jobs ([example](https://app.circleci.com/pipelines/github/facebook/react-native/9280/workflows/21e6e59c-d853-47a1-af62-1368c8ce10ce/jobs/203983)) following #30637, ultimately due to jestjs/jest#10685 dropping support for non-LTS versions in the Node v12 release line.

Luckily, the Windows executor [does ship with nvm](circleci/circleci-docs#3733) so we can use that to install a desired Node version. Rather than just pinning a later v12 release that is LTS, we pin a v14 release that is currently the most recent LTS version.

NOTE: The nvm on CircleCI is https://github.com/coreybutler/nvm-windows, not https://github.com/nvm-sh/nvm, and the two aren't interchangeable. [nvm-windows has no functionality to install the latest version of a release line](coreybutler/nvm-windows#156) so we're forced to specify an exact version, which will need to be bumped manually in the future. This isn't great, but IMO it's no worse than the current situation, where we use whichever stale version of Node happens to be bundled with the Windows CircleCI executor.

Changelog:
[Internal]

Reviewed By: GijsWeterings

Differential Revision: D28896581

fbshipit-source-id: a412376cf36054de49efa49866fe60dd964567c5
@ingles98
Copy link

Any updates on this? It has been 5 years and I just started using NVM and I came to check why would I get Node 14.0.0 instead of latest if i specify only the Major?

Setito pushed a commit to Setito/react-native that referenced this issue Jul 17, 2021
Summary:
Pull Request resolved: facebook#31656

CircleCI's Windows executor currently ships with a pre-LTS release of Node v12, breaking our Windows jobs ([example](https://app.circleci.com/pipelines/github/facebook/react-native/9280/workflows/21e6e59c-d853-47a1-af62-1368c8ce10ce/jobs/203983)) following facebook#30637, ultimately due to jestjs/jest#10685 dropping support for non-LTS versions in the Node v12 release line.

Luckily, the Windows executor [does ship with nvm](circleci/circleci-docs#3733) so we can use that to install a desired Node version. Rather than just pinning a later v12 release that is LTS, we pin a v14 release that is currently the most recent LTS version.

NOTE: The nvm on CircleCI is https://github.com/coreybutler/nvm-windows, not https://github.com/nvm-sh/nvm, and the two aren't interchangeable. [nvm-windows has no functionality to install the latest version of a release line](coreybutler/nvm-windows#156) so we're forced to specify an exact version, which will need to be bumped manually in the future. This isn't great, but IMO it's no worse than the current situation, where we use whichever stale version of Node happens to be bundled with the Windows CircleCI executor.

Changelog:
[Internal]

Reviewed By: GijsWeterings

Differential Revision: D28896581

fbshipit-source-id: a412376cf36054de49efa49866fe60dd964567c5
@Mart-Bogdan
Copy link

It seems to work correctly now, at

nvm --version

Running version 1.1.9.

@Mart-Bogdan
Copy link

So can be closed, I guess.

@coreybutler
Copy link
Owner

Closing because this behavior does exist now. Issue #708 addresses partial version support, which already has a merged PR associated with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2.0.0
Backlog
Development

No branches or pull requests