Open ryanmurakami opened 8 years ago
Did you try, nvm use system?
You can make it the default
nvm alias default system
It may be a good idea for us to consider installing and using the same folder schema as nvm /cc @ljharb On Jul 1, 2016 2:14 PM, "Ryan Lewis" notifications@github.com wrote:
With nvm https://github.com/creationix/nvm installed, it seems that the install of an updated version doesn't quite work. After updating from the installer, the binary is installed in /usr/bin/local/, but $ which node shows that nvm still has the global node. (Example output: /Users/rylewis/.nvm/versions/node/v6.2.0/bin/node).
It would be nice to either detect that a version manager is being used and message something, or perhaps override the location of node (this might be a little destructive and may need to do some specific messaging).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nodejs/installer/issues/19, or mute the thread https://github.com/notifications/unsubscribe/AAecV8YIAxYZBRyrf6FjNRj8JZmCUi5Wks5qRYMpgaJpZM4JDfCp .
@TheAlphaNerd Thanks for the reply! I know there's ways around it. I was just thinking from a user standpoint that may not quite understand how these things work. I think either having some messaging, or options to override nvm, would improve the user experience. Of course, I know this project is in its inception, just wanted to throw in my two cents. :-)
The hope is that messaging/auto-resolution will prevent issues like #20 from popping up in the future. :-)
@ryanmurakami after using the installer, does nvm use system
use the proper one? I'd not expect the node installer to do anything except install a system node, which nvm works with just fine.
I think at this early stage, I would mention nvm
in the README and if you can detect it during runtime, log a warning and maybe reference this issue?
@ljharb Yep, nvm use system
will set the current resolving node to the /usr/local/bin one.
@gr2m I agree, a README mention for now should be fine, but I think smoothing out this type of thing should stay as a goal for the installer. In that regard, a log to the console should probably be avoided, and a message in the installer window should be the target.
We should at least detect nvm and warn them that it won't be compatible.
Long term this package should probably include a version manager. However, that version manager will need to work on Windows and probably be in pure Node.js rather than the bash based ones that seem to dominate the current ecosystem.
@mikeal how could you have a node version manager written in node? A version manager needs to be able to install a version of node on a system that lacks it entirely.
It can rely on Node.js if it lives in the Installer :)
Are there other node version managers to be aware of? I don't think homebrew or n would cause any overlap with the installer. Can't really think of any other ones though...
also nave, avn, nvm-windows, plus i'm sure a handful of others.
Agreed with @mikeal for true portability this would have to be able to run on Windows. Might be a good opportunity to have a node-only solution to version management.
With nvm installed, it seems that the install of an updated version doesn't quite work. After updating from the installer, the binary is installed in
/usr/bin/local/
, but$ which node
shows that nvm still has the global node. (Example output:/Users/rylewis/.nvm/versions/node/v6.2.0/bin/node
).It would be nice to either detect that a version manager is being used and message something, or perhaps override the location of node (this might be a little destructive and may need to do some specific messaging).