[Bug] "yarn node" command sometimes uses wrong node.exe on Windows

[a-sore]

yarn node sometimes doesn't resolve node.exe to the one Yarn was started with. This has only happened on Windows.

To Reproduce

• Create any new yarn 2 project on Windows.
• Run yarn node using a predefined path to node.exe and Yarn: e.g. ..\path-to-node\node.exe ..\path-to-yarn\yarn-berry.js node
• If the supplied node.exe is not in the current directory, Yarn will use the first node.exe found in the user's PATH, instead of the one invoked by the user.

This means only this works properly: .\node.exe ..\path-to-yarn\yarn-berry.js node ...

This doesn't (uses node.exe from PATH): ..\any-other-path\node.exe ..\path-to-yarn\yarn-berry.js node ...

Environment

• OS: Windows 10
• Node version: irrelevant
• Yarn version: 2.0.0-rc.30

[bgotink]

I've tested this and can reproduce it on PowerShell, though it works fine in git BASH.

Ignore the mention above, I thought it worked after a fix for another PR but I was testing in BASH.

Old (false) theory explaining the issue, see comment below instead


The issue lies with PATHEXT. The windows shells CMD and PowerShell search all folders in the PATH not just for files matching the executable's name, but also for those matching the executable's name with one of the PATHEXT file extensions.
The final executable it runs isn't just defined by the order of the PATH, but also by the order of the PATHEXT.

C:\Some\Folder> yarn exec where node
C:\Users\User\AppData\Temp\xfs-hash\node <-- note, I'm running code with #1386 in it, so the if you use the master branch yarn will not log this line
C:\Users\User\AppData\Temp\xfs-hash\node.cmd
C:\Program Files\nodejs\node.exe

You'd think Windows will execute the first file it finds, but sadly the order of PATHEXT prevails over the order of PATH, and PATHEXT is

C:\Some\Folder> $Env:PATHEXT
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW;.CPL

.EXE comes before .CMD, so the exe wins and gets executed.

C:\Some\Folder> node --version
14.3.0
C:\Some\Folder> C:\path\to\node-12\node --version
12.16.3

C:\Some\Folder> C:\path\to\node-12\node .yarn/releases/yarn-berry.js exec node --version
14.3.0
C:\Some\Folder> C:\path\to\node-12\node .yarn/releases/yarn-berry.js exec node.cmd --version
12.16.3

The reason it works if you have node.exe in the current folder is because CMD/PowerShell first look for <executable name>.exe in the current folder and only look in the PATH if that executable doesn't exist.

I'm going out on a limb here and say this is probably one of the reasons for npm's --scripts-prepend-node-path flag.

[bgotink]

Okay, I've looked into this some more, and we're in a pretty unique situation.

First things first: I've opened moxystudio/node-cross-spawn#133 to fix this bug.

What exactly is going on?

Let's start with some context:

• On Windows the PATH environment value isn't necessarily named PATH. Windows environment keys are case insensitive, so on my maching it's actually called Path.
  Yarn 2 is always using the PATH key when passing the environment into cross-spawn.
• libuv can only spawn .exe or .com files on Windows. If we ask it to spawn node, it will completely ignore the node.cmd yarn puts on the PATH and use C:\Program Files\nodejs\node.exe instead.
• cross-spawn resolves what file should be executed. If that file is not a .exe or .com file, cross-spawn will actually spawn cmd.exe which then executes the actual command.

What's happening?

1. Because cross-spawn didn't pass in the environment we pass into its options into the path-key package, that uses process.env to detect the name of the PATH environment variable.
   On my system that results in Path.
2. However, options.env.Path is undefined (we pass in options.env.PATH instead). So the call to which to look up node gets passed an undefined path, which makes it fall back to the PATH environment variable in process.env (in this case process.env.Path).
3. This PATH doesn't contain the temporary folder yarn has created, so which actually resolves node to C:\Program Files\nodejs\node.exe.
4. cross-spawn then thinks "okay, that's an .exe, I don't need to wrap that with cmd.exe."
5. Node's child_process is asked to spawn node directly, which asks libuv to spawn node.
6. libuv only looks for node.exe and node.com on the PATH, so it ignores our node.cmd and executes C:\Program Files\nodejs\node.exe instead