-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Comments
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. |
np, sounds good! |
Looks like we must to tell nvm Why not tell it in Error like |
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. |
@jamestalmage - So support for I just released a new version. I don't think it behaves exactly as desired, but it won't error out on something like Since this doesn't address the enhancement request in it's entirety, I'm going to leave this open. |
Can this feature request also cover That's the command I use the most and it'd be much more convenient to do |
@insin - Yeah, |
@coreybutler if I remember correctly, UNIX |
Some other aliases would also be useful, like unix nvm or node's oficial docker image nvm install lts -> installs latests lts version |
I'm gonna sort of weigh in here(I hope this is the right place for it) and say that I tried to do
The paths there referring to |
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. |
@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). |
Hello @coreybutler, any hope it would be fixed? 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 |
Ok, I see there are also two issues for mvn use Hmm, I'm wondering is that the same code path? I think not, |
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
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
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? |
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
It seems to work correctly now, at
|
So can be closed, I guess. |
Closing because this behavior does exist now. Issue #708 addresses partial version support, which already has a merged PR associated with. |
My Environment
I have already...
My issue is related to (check only those which apply):
Expected Behavior
nvm install 5
would install latest version (whatever it was)
Actual Behavior
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!
The text was updated successfully, but these errors were encountered: