fnm
fnm copied to clipboard
Schniz
Node not switching
I've installed fnm on mac using homebrew, and put eval "$(fnm env)" inside my .zshrc.
It appears to work, but when I run fnm use <version>, and test that version using node -v, output versions are different, as if fnm didn't switch it at all.
It only works after I re-source .zshrc. I guess it's not supposed to work that way...
Is there anything I have to do to make it work that I overlooked?
/usr/local/sbin:/var/folders/_r/slz2zc7s2hs59_8rtc3lww900000gn/T/fnm_multishells/13700_1637656413932/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/Library/Apple/usr/bin
It's weird, because when I launch VSCode from the terminal, (so it uses the proper node version) and check the node version from within it (using its integrated terminal), it outputs proper version.
Only the current terminal session seems to not be updating
Maybe there's a need for rehash?
Can you show me:
which node
$FNM_MULTISHELL_PATH/bin/node --version
try running rehash after fnm use 14 please :) just to make sure that it works
yep, that seems to fix it - do I have to run it every time after changing the version though?
I need to check why this is happening. It did not happen to me and I'm using Zsh, maybe that's a newer version and we need to fix fnm somehow.
@Schniz it appears to be fixed since https://github.com/Schniz/fnm/releases/tag/v1.28.1
I've taken a look at the PR, and although I don't know a thing when it comes to Rust, maybe this line is related? (based on hashmap keyword)
Anyway, let's close this and I'll report back if I'll encounter it again
weird, it should not affect the shell binary resolution 🤔 for some reason, rehashing is required sometimes. I don't know why, but I have an idea how to work it out and fix other issues with the same fix :)
closing for now :)
PATH:
/usr/local/sbin:/Users/selrond/Library/Caches/fnm_multishells/85078_1644225259663/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
hash -t node throws hash: bad option: -t
thx, here it is:
hash node=/Users/selrond/Library/Caches/fnm_multishells/4390_1644223494403/bin/node
I need to check why this is happening. It did not happen to me and I'm using Zsh, maybe that's a newer version and we need to fix fnm somehow.
@Schniz Any chance I could help to pin this issue down?
There’s a hack I researched. Rehashing on zsh automatically. I’ll open a PR tomorrow and then you can test it before merging. Wdyt?
I’m no expert in zsh, so whatever works 😄
I’ve noticed a strange(?) behavior - once I run rehash once in a terminal session, it seems to be working (tried switching versions back and forth and running node -v)
However, this is no longer a case:
when I launch VSCode from the terminal, (so it uses the proper node version) and check the node version from within it (using its integrated terminal), it outputs proper version
where node:
output from main terminal
/Users/selrond/Library/Caches/fnm_multishells/3981_1644995919375/bin/node
/opt/homebrew/bin/node
VSCode terminal after launching it
/opt/homebrew/bin/node
/Users/selrond/Library/Caches/fnm_multishells/3981_1644995919375/bin/node
/opt/homebrew/bin/node
after rehash:
/Users/selrond/Library/Caches/fnm_multishells/5549_1644996562545/bin/node
/opt/homebrew/bin/node
/Users/selrond/Library/Caches/fnm_multishells/3981_1644995919375/bin/node
/opt/homebrew/bin/node
I do not use VSCode so it'll be hard for me to debug & verify. I don't know what it's running in the integrated shell, etc.
rehash makes sense, this is why we're doing it 🤔
https://github.com/Schniz/fnm/blob/1acb2892c502c73e4acd0469410f1b8ffa687678/src/shell/zsh.rs#L26-L28
my idea was to call rehash before calls to node or before any call (yet this feels... not good 😁)
I’ve solved the VSCode problem by not running its terminal as a login shell, so that’s out of question.
Only the rehash-needed problem remains
I’ve "solved" it for now by uninstalling system nodejs (installed via homebrew).
Not exactly happy with the solution, but it seems to work.
Really weird, I’ve never came across rehash previously, and I’ve been tinkering with terminal setup for some years now...
Not sure if this is related. Is it possible to save the node version preference once I quit the current terminal session?
I have a default node version (v12) but I would want to use (v16) in my project. After setting v16 with fnm use, if I access the project from another terminal window or close the terminal and open it again in my project folder, the node version is reset to v12.
Anybody have a clue on how I can solve this?
I'm facing the same issue with bash 5.1.16 and fnm 1.31.0, specifically when switching between the system node version and one managed by fnm. The output of which node will show the correct path in both cases, but the path will be cached to the previous location until I manually run hash -d node (after which it works as expected). Switching between fnm managed versions is fine because the path is still /run/user/1000/fnm_multishells/.../bin/node after switching, the problem only comes when running fnm use system because the path changes to /usr/bin/node in that case.
I have same issue here. I'm using zsh 5.8.1 and fnm 1.29.2. The problem only appears when the system nodejs is involved. When I currently use the system node it works perfectly fine. But when I change the node version (either manually fnm use or when I cd to a directory with .node-version) it node version does not work. which node shows proper path (like /tmp/fnm_multishells/7982_1649893314783/bin/node) but node still uses the system node (/usr/bin/node checked through hash -m "node").
I also have the same problem. When switching node version from system to v14, the version doesn't change unless rehash is called. However, after calling rehash, switching back to system then v14 will switch the version.
