"'node': No such file or directory" when using Git in VSCode on Windows

[aczekajski]

I installed fnm (v 1.38.1) on Windows using choco and then, since I'm using git-bash, I added this to my ~/.bashrc:

eval "$(fnm env --shell bash)"

It works fine for literally everything I run myself inside git-bash.

But when I try to just commit anything via VSCode's UI:

I get this error:

This is the only log that it gives me:

> git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file -
/usr/bin/env: ‘node’: No such file or directory

When I run the same command manually in git-bash, it works fine.

I think it's not a general problem of VSCode because commiting from VSCode UI worked just fine when I was using nvm-windows which I uninstalled to try fnm.

I don't have any other shells installed and my VSCode settings all point to git-bash to use as a terminal. The output doesn't seem like something that PowerShell or cmd might spit out as well. I am completely lost on what the git inside vscode might be doing for that error to be happening 😭

I thought that it's maybe related to #604 or #486 but it's hard to tell honestly.

[aczekajski]

I was thinking why git would possibly be even trying to run node when committing and it appeared to me that it might be related to git hooks. I dived into .git/hooks of my repo and there it is: all my hooks are scripts starting with this line:

#!/usr/bin/env node

So it seems even more related to #604 now.

The strange thing is that it runs fine if I run git commands myself from git-bash. I made a simple script like that:

#!/usr/bin/env node

console.log("Hello from Node", process.version);

and running it myself works just fine:

$ ./test-usr-bin-env-script
Hello from Node v22.14.0

[aczekajski]

I temporarily replaced one of the hooks with this:

#!/bin/sh

echo "Node: $(which node)"
echo "User: $(whoami)"
echo $SHELL
echo $(cygpath -w $SHELL)

to see what the heck is being run. Turns out it's the same shell as the one being run when I run the command myself. User is also the same. However, the which command gives me this:

which: no node in (
    /mingw64/libexec/git-core
    /mingw64/bin
    /usr/bin
    /c/Users/my.user/bin
    /c/Program Files (x86)/Common Files/Oracle/Java/java8path
    /c/Program Files (x86)/Common Files/Oracle/Java/javapath
    /c/WINDOWS/system32
    /c/WINDOWS
    /c/WINDOWS/System32/Wbem
    /c/WINDOWS/System32/WindowsPowerShell/v1.0
    /c/WINDOWS/System32/OpenSSH
    /c/Program Files (x86)/Box/Box Edit
    /c/Program Files/RedHat/Podman
    /c/ProgramData/chocolatey/bin
    /c/Program Files/WireGuard
    /cmd
    /c/Users/my.user/AppData/Local/Microsoft/WindowsApps
    /c/Users/my.user/AppData/Local/Programs/Microsoft VS Code/bin
)

so it seems that when VSCode runs the git-bash, it does not source ~/.bashrc and there are no fnm-related paths in $PATH.

Seems that it's the same problem as #486.

[aczekajski]

The workaround I used for now:

1. Open git-bash as admin.
2. Run:

echo '#!/bin/sh' > "$(dirname $(which fnm))/global-node"
echo 'eval "`fnm env`"' >> "$(dirname $(which fnm))/global-node"
echo 'fnm use > /dev/null 2>&1' >> "$(dirname $(which fnm))/global-node"
echo 'node "$@"' >> "$(dirname $(which fnm))/global-node"
ln -s "$(which fnm)" /usr/bin/fnm
ln -s "$(dirname $(which fnm))/global-node" /usr/bin/node

It creates this small script in fnm's directory:

#!/bin/sh
eval "`fnm env`"
fnm use > /dev/null 2>&1
node "$@"

and then links /usr/bin/node to point to this script.

It's probably bad but it works for now. I hope fnm would get this properly resolved at some point.

[aczekajski]

Dunno what I did wrong but actually doing ln -s creates a hard copy on my machine so later changes to the global-node were not reflected. Replacing the files with links created with windows native mklink causes the processes trying to run /usr/bin/node to hang indefinitely and start to eat up lots of resources (what's funny, actually reported as used by "System", not by vscode or node or bash or whatever else). Maybe it causes some link loop? Didn't investigate further but it might work as a warning for future windows implementation of fnm's global node ^^'

[sosweetham]

Linking back from #486

Pointer for MacOS, saving future readers a search 😄

This would not be allowed if System Integrity Protection isn't disabled, as by default with SIP enabled, users cannot write to /usr/bin (even with sudo)

However, an alternative symlink would would be /usr/local/bin/fnm & /usr/local/bin/node and everything else should work the same.

Final command sequence/script becomes

echo '#!/bin/sh' > "$(dirname $(which fnm))/global-node"
echo 'eval "`fnm env`"' >> "$(dirname $(which fnm))/global-node"
echo 'fnm use > /dev/null 2>&1' >> "$(dirname $(which fnm))/global-node"
echo 'node "$@"' >> "$(dirname $(which fnm))/global-node"
sudo ln -s "$(which fnm)" /usr/local/bin/fnm
sudo ln -s "$(dirname $(which fnm))/global-node" /usr/local/bin/node

[FaganSC]

I found a simple fix: add your FNM Path "C:\Users{{USERNAME}}\AppData\Roaming\fnm\aliases\default" to your system environment variable under "Path".

$fnmPath = "C:\Users\{{USERNAME}}\AppData\Roaming\fnm\aliases\default"
$env:Path += ";$($fnmPath)"

Write-Output $env:Path.split(";")

This fixed the error of VS Code Command Line not finding Node

[aczekajski]

That won't respect the .nvmrc but if you don't care, that's ok as well