Custom electron build fails with electron-builder 26.0.2 (works with 26.0.1), suspect #8785

[ivanggq]

Our project uses a custom electron build.

In our .npmrc file, we specify:

electron_mirror=https://_custom_location_/electron/builds/
electron_custom_dir=v36.4.0-14

In our electron-builder.yml, we specify:

electronDownload:
  mirror: https://_custom_location_/electron/builds/
  customDir: v36.4.0-14
nativeRebuilder: legacy

Since electron-builder 26.0.2, the build fails with error:

gyp http GET https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz
gyp http 404 https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz
gyp WARN install got an error, rolling back install
gyp ERR! configure error 
gyp ERR! stack Error: 404 response downloading https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz
gyp ERR! stack at go (/SANITIZED/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/lib/install.js:223:21)
gyp ERR! stack at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
gyp ERR! stack at async install (/SANITIZED/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/lib/install.js:63:18)
gyp ERR! stack at async getNodeDir (/SANITIZED/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:79:7)
...

Note the invalid URL https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz

When working (with 26.0.1), it downloads the correct URL https://_custom_location_/electron/builds/v36.4.0-14/electron-v36.4.0-darwin-x64.zip

I suspect #8785.

On inspection of node-gyp/lib/configure.js:79:7 and the code in app-builder-lib, it seems to be around the npm_config_disturl and not honoring the electron_custom_dir it seems (v36.4.0-14 vs v36.4.0), but might be wrong.

The difficult part is that:

• The issue for us happens only for Mac builds (not for Windows)
• It happens only in our CI builds (Jenkins) and not usually locally on my machine
  • It happened only once on my local machine and then I cannot repro locally anymore

So not sure if this is some race condition or maybe something in the env vars... I will continue looking on my end to see if I can find something else but wanted to file this ticket in case you have any idea or suggestion. Thanks.

Edit: Once I deleted the ~/.electron-gyp folder on Mac, I started reproducing the issue reliably on my local Mac too. For clarity, this seems to be the folder passed here: npm_config_devdir: getElectronGypCacheDir().
I am unable to repro the issue on Windows, even when deleting the .electron-gyp, or %localappdata%\electron\Cache and some other cache folders I found.

[ivanggq]

Here is a bigger snippet from the error from my local Mac, with verbose npm logging enabled.

It seems to me input version string "36.4.0" should be using 36.4.0-14 instead... is it maybe an issue of passing the custom_dir arg to node-gyp somehow too?

    gyp info it worked if it ends with ok
    gyp verb cli [
    gyp verb cli '/Users/ivang/.volta/tools/image/node/22.16.0/bin/node',
    gyp verb cli '/Users/ivang/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js',
    gyp verb cli 'rebuild'
    gyp verb cli ]
    gyp info using node-gyp@11.0.0
    gyp info using node@22.16.0 | darwin | x64
    gyp verb clean removing "build" directory
    gyp verb download using dist-url https://_custom_location_/electron/builds/
    gyp verb find Python Python is not set from command line or npm configuration
    gyp verb find Python Python is not set from environment variable PYTHON
    gyp verb find Python checking if "python3" can be used
    gyp verb find Python - executing "python3" to get executable path
    gyp verb find Python - executable path is "/Library/Frameworks/Python.framework/Versions/3.10/bin/python3"
    gyp verb find Python - executing "/Library/Frameworks/Python.framework/Versions/3.10/bin/python3" to get version
    gyp verb find Python - version is "3.10.0"
    gyp info find Python using Python version 3.10.0 found at "/Library/Frameworks/Python.framework/Versions/3.10/bin/python3"
    gyp verb get node dir compiling against --target node version: 36.4.0
    gyp verb download using dist-url https://_custom_location_/electron/builds/
    gyp verb install input version string "36.4.0"
    gyp verb install installing version: 36.4.0
    gyp verb install --ensure was passed, so won't reinstall if already installed
    gyp verb install version not already installed, continuing with install 36.4.0
    gyp verb ensuring devDir is created /Users/ivang/.electron-gyp/36.4.0
    gyp verb created devDir /Users/ivang/.electron-gyp/36.4.0
    gyp http GET https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz
    gyp http 404 https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz
    gyp WARN install got an error, rolling back install
    gyp verb remove using node-gyp dir: /Users/ivang/.electron-gyp
    gyp verb remove removing target version: 36.4.0
    gyp verb remove removing development files for version: 36.4.0
    gyp ERR! configure error 
    gyp ERR! stack Error: 404 response downloading https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz
    gyp ERR! stack at go (/Users/ivang/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/lib/install.js:223:21)
    gyp ERR! stack at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    gyp ERR! stack at async install (/Users/ivang/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/lib/install.js:63:18)
    gyp ERR! stack at async getNodeDir (/Users/ivang/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:79:7)
    gyp ERR! stack at async run (/Users/ivang/.volta/tools/image/node/22.16.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:81:18)
    gyp ERR! System Darwin 24.5.0

[ivanggq]

Or maybe the problem is simpler than that and the issue is that it tries to use:
https://_custom_location_/electron/builds/v36.4.0/node-v36.4.0-headers.tar.gz
instead of the working:
https://electronjs.org/headers/v36.4.0/node-v36.4.0-headers.tar.gz?

Does the change in #8785 require custom electron locations to have the v36.4.0/node-v36.4.0-headers.tar.gz files?

[ivanggq]

I am still not clear why Windows does not have this issue. After I deleted the %HOMEPATH%\.electron-gyp folder, it is no longer created on Windows. So not sure sure why Windows does not need these Node headers and Mac does...

[ivanggq]

Looking at #8785 , the original property used was npm_config_electron_headers_disturl, but then it was changed to npm_config_electron_mirror, which adds a second responsibility and meaning to npm_config_electron_mirror. I am not too familiar what the Node headers are and if you have a custom Electron whether you need custom Node headers too, but it seems to me custom Electron != custom Node headers. If so, then maybe using a dedicated property like npm_config_electron_headers_disturl makes more sense? So that they can be configured independently?

[ivanggq]

Sorry to ping you @lamawithonel and @mmaietta directly here, but curious what you think about this ticket? Thanks.

[ivanggq]

I think I now know why this issue does not happen on Windows for our project. Our project has 2-3 native dependencies that are only available for Windows. For example: win-verify-signature. On Windows, their prebuilt binaries are downloaded directly, while on Mac, electron-builder goes into build native dependency from sources mode and this is is where it starts downloading the Node headers it seems. I am aware that settings like nativeRebuilder and similar can control how native deps are handled, but since in our project we use several different dependencies from different sources, they all have different model for building and/or installing their prebuilts, so we had to settle with what worked for all of them, which is nativeRebuilder: legacy.

If we had finer control over how each native dependency is built/installed, and whether to even include it per platform, maybe this issue could be avoided.

[mmaietta]

Sorry, been on an extended vacation. I'll try to take a look at this week!

[ivanggq]

Thanks @mmaietta .

[ivanggq]

Hi, just checking if there is any update on this issue? Thanks.

[ivanggq]

Hi @mmaietta , sorry to ping you, just checking if you have plans to look into this soon.

[mmaietta]

So, this might actually get resolved through #8827, but I need to rewrite the PR so that it's not a breaking change in terms of a migration

[github-actions]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment, or this will be closed in 30 days.

[ivanggq]

Still relevant.