The path of node js is not correctly recognized on Windows

[Losses]

• Electron-Builder Version: 22.11.7

• Node Version: 14.17.3

• Electron Version: 13.1.6
• Electron Type (current, beta, nightly): current

• Target: N/A

While running installing-app-deps or any other commands, following error occurs:

  • electron-builder  version=22.11.7
  • loaded configuration  file=package.json ("build" field)
  • installing production dependencies  platform=win32 arch=x64 appDir=D:\dev\cryptoElectron\src
  • spawning        command=C:\Users\Losse\AppData\Local\Temp\xfs-8e15e263\node yarn install --production cwd=D:\dev\cryptoElectron\src
  • exited          command=node code=-4058 pid=undefined
  ⨯ spawn C:\Users\Losse\AppData\Local\Temp\xfs-8e15e263\node ENOENT  failedTask=installAppDeps stackTrace=Error: spawn C:\Users\Losse\AppData\Local\Temp\xfs-8e15e263\node ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:269:19)
    at onErrorNT (internal/child_process.js:467:16)
    at processTicksAndRejections (internal/process/task_queues.js:82:21)

This may relate to the spawn method, the closest code I found is:

electron-builder/packages/app-builder-lib/src/util/yarn.ts

Line 108 in 5b4305e

return spawn(execPath, execArgs, {

[Losses]

Donation attached:

[mmaietta]

Hi there!
Can you please rerun with env var DEBUG=electron-builder and post the logs back?

[Losses]

@mmaietta Nothing happened

[Losses]

@mmaietta Okay, it's a pretty comperhensive bug:

1. Yarn 3 was released, but isYarn2 didn't considered it, related code:
   

   electron-builder/packages/app-builder-lib/src/util/yarn.ts

   Line 86 in 28cb86b

   const isYarn2 = npmUserAgent != null && npmUserAgent.startsWith("yarn/2.")

It's recommend to rename it with isYarnBerry which will reflect what really happened.

Another suggestion is: there will be yarn 4, 5, and more, we can't writing things like this:

npmUserAgent.startsWith("yarn/2.") || npmUserAgent.startsWith("yarn/3.") || npmUserAgent.startsWith("yarn/4.") || npmUserAgent.startsWith("yarn/5.") // ...

The first solution comes to my mind is using something like app-root-path, trying to find if there's a folder named .yarn, if there's one, it is running yarn berry.

Or, just simply use a regex, like this:

const MOCK_UA = `yarn/3.0.0-rc.9 npm/? node/14.17.3 win32 x64`;
const regex = /yarn\/(\d+)\./gm;

const yarnVersionMatch = regex.exec(MOCK_UA);
const yarnMajorVersion = yarnVersionMatch?.[1];
const isYarnBerry = yarnMajorVersion >= 2;

---

The second bug is, process.env.npm_execpath didn't give the correct executable path on Windows.

electron-builder/packages/app-builder-lib/src/util/yarn.ts

Line 83 in 28cb86b

let execPath = process.env.npm_execpath || process.env.NPM_CLI_JS

What was given:

'C:\\Users\\Losse\\AppData\\Local\\Temp\\xfs-3b46ab91\\yarn'

This didn't work on my machine.

what I did is using which, this package give me the correct executable path of yarn, like this:

    if (isYarn2) {
      const yarnPath = which.sync('yarn');
      execPath = yarnPath;
    }

The new path I got:

'C:\\Users\\Losse\\AppData\\Local\\Temp\\xfs-5f0bf6c0\\yarn.CMD'

With these two patches, the problem was fixed, we should have a discuss about how to make a proper fix about this bug, since many windows users may face the same problem.

[mmaietta]

Wowza, that's quite the investigative results. I definitely would not have picked up on it being a new version of yarn. I probably need to add that into the New Issue template.

We can definitely get the yarn berry support into a PR.

I'm not opposed to using which, but the downside is that being able to specify via env would need to remain to be backward compatible, particularly for CI environments.
Are you able to set/override NPM_CLI_JS for your work environment?

[Losses]

@mmaietta since process.env.npm_execpath already have a value, process.env.NPM_CLI_JS won't be used.

I'm really headache about how to handle this, adding another env variable like USE_YARN_COMMAND which will trigger which may be a solution? How can we name this variable is another problem...

[mmaietta]

Yeah, clearly something is needed, I'm just confused, why is the default process.env.npm_execpath path not having the extension suffix .CMD? That seems more local env related tbh. Do you have another machine you can test with?

[Losses]

@mmaietta Ehhhh.... It's hard but I'll try to find one...

[mmaietta]

Or a VM could work?

If you can put together a sample repo, I can also bootcamp into windows and try it out.

[Losses]

Or a VM could work?

If you can put together a sample repo, I can also bootcamp into windows and try it out.

I'll have a try

[Losses]

Or a VM could work?

If you can put together a sample repo, I can also bootcamp into windows and try it out.

@mmaietta

I've tried on another Windows machine, same thing happens, just start with a blank electron-react-boilerplate and you can see the bug