feat: add `ELECTRON_INSTALL_` env vars by erickzhao · Pull Request #49981 · electron/electron

erickzhao · 2026-02-28T07:01:58Z

Description of Change

Due to the binary no longer installing on npm install and us getting warnings from npm for setting unknown config values for npm install --platform win32 electron, here are two new env vars:

# before: pass npm config flag on install command
npm install --platform=mas electron --save-dev
# after: add env var when you first run the Electron command
npm install electron --save-dev
ELECTRON_INSTALL_PLATFORM=mas npx electron . --no

cc @electron/wg-api

Checklist

PR description included
I have built and tested this PR
npm test passes
relevant API documentation, tutorials, and examples are updated and follow the documentation style guide
PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: added ELECTRON_INSTALL_PLATFORM and ELECTRON_INSTALL_ARCH variables to install binaries from other platforms and architectures.

VerteDinde

Code looks good to me, pending API approval 👍

jkleinsc

Overall LGTM, but I think it would be helpful to list the arch and platforms we support.

jkleinsc · 2026-03-02T21:42:12Z

+`arm64` machine), you can set the `ELECTRON_INSTALL_ARCH` environment variable:

-```shell
-npm install --arch=x64 electron
+```sh
+# Inside an npm script or with npx
+ELECTRON_INSTALL_ARCH=x64 electron .
 ```

 In addition to changing the architecture, you can also specify the platform
 (e.g., `win32`, `linux`, etc.) using the `--platform` flag:

-```shell
-npm install --platform=win32 electron
+```sh
+# Inside an npm script or with npx
+ELECTRON_INSTALL_PLATFORM=mas electron .


Can we explicitly list what arches and platforms we support?

Depends from version to version, but I added a little hint here: 1d3a211

Under the hood, @electron/get doesn't even define valid arch/platform combos in its types.

jkleinsc

API LGTM

codebytere

API LGTM

release-clerk · 2026-03-12T14:09:53Z

Release Notes Persisted

added ELECTRON_INSTALL_PLATFORM and ELECTRON_INSTALL_ARCH variables to install binaries from other platforms and architectures.

The postinstall script resolves two things from the target platform: 1. Which artifact to download, via `downloadArtifact({ platform, ... })`. Since electron#49981, `platform` is derived from `ELECTRON_INSTALL_PLATFORM || npm_config_platform || process.platform`. 2. Which executable path to use for the `isInstalled()` cache check and for the `path.txt` marker written after extraction, via `getPlatformPath()`. `getPlatformPath()` was not updated with the rest of that change and still falls back to `npm_config_platform || os.platform()` only. As a result, passing `ELECTRON_INSTALL_PLATFORM` (as documented in `docs/tutorial/installation.md`) causes the two to disagree: the download fetches the requested platform's zip, but `path.txt` and the path sanity check are written against the host platform's executable name. That in turn makes `isInstalled()` always return `false` on subsequent runs (forcing redundant re-downloads) and makes the executable path recorded in `path.txt` wrong for the artifact that was actually extracted (e.g. `electron` written alongside a `darwin`/`win32` build). Check `ELECTRON_INSTALL_PLATFORM` first, matching the resolution used for `downloadArtifact`. Assisted-By: Claude Opus 4.6 Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

The postinstall script resolves two things from the target platform: 1. Which artifact to download, via `downloadArtifact({ platform, ... })`. Since electron#49981, `platform` is derived from `ELECTRON_INSTALL_PLATFORM || npm_config_platform || process.platform`. 2. Which executable path to use for the `isInstalled()` cache check and for the `path.txt` marker written after extraction, via `getPlatformPath()`. `getPlatformPath()` was not updated with the rest of that change and still falls back to `npm_config_platform || os.platform()` only. As a result, passing `ELECTRON_INSTALL_PLATFORM` (as documented in `docs/tutorial/installation.md`) causes the two to disagree: the download fetches the requested platform's zip, but `path.txt` and the path sanity check are written against the host platform's executable name. That in turn makes `isInstalled()` always return `false` on subsequent runs (forcing redundant re-downloads) and makes the executable path recorded in `path.txt` wrong for the artifact that was actually extracted (e.g. `electron` written alongside a `darwin`/`win32` build). Check `ELECTRON_INSTALL_PLATFORM` first, matching the resolution used for `downloadArtifact`. Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

The postinstall script resolves two things from the target platform: 1. Which artifact to download, via `downloadArtifact({ platform, ... })`. Since #49981, `platform` is derived from `ELECTRON_INSTALL_PLATFORM || npm_config_platform || process.platform`. 2. Which executable path to use for the `isInstalled()` cache check and for the `path.txt` marker written after extraction, via `getPlatformPath()`. `getPlatformPath()` was not updated with the rest of that change and still falls back to `npm_config_platform || os.platform()` only. As a result, passing `ELECTRON_INSTALL_PLATFORM` (as documented in `docs/tutorial/installation.md`) causes the two to disagree: the download fetches the requested platform's zip, but `path.txt` and the path sanity check are written against the host platform's executable name. That in turn makes `isInstalled()` always return `false` on subsequent runs (forcing redundant re-downloads) and makes the executable path recorded in `path.txt` wrong for the artifact that was actually extracted (e.g. `electron` written alongside a `darwin`/`win32` build). Check `ELECTRON_INSTALL_PLATFORM` first, matching the resolution used for `downloadArtifact`. Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

…#51029) The postinstall script resolves two things from the target platform: 1. Which artifact to download, via `downloadArtifact({ platform, ... })`. Since electron#49981, `platform` is derived from `ELECTRON_INSTALL_PLATFORM || npm_config_platform || process.platform`. 2. Which executable path to use for the `isInstalled()` cache check and for the `path.txt` marker written after extraction, via `getPlatformPath()`. `getPlatformPath()` was not updated with the rest of that change and still falls back to `npm_config_platform || os.platform()` only. As a result, passing `ELECTRON_INSTALL_PLATFORM` (as documented in `docs/tutorial/installation.md`) causes the two to disagree: the download fetches the requested platform's zip, but `path.txt` and the path sanity check are written against the host platform's executable name. That in turn makes `isInstalled()` always return `false` on subsequent runs (forcing redundant re-downloads) and makes the executable path recorded in `path.txt` wrong for the artifact that was actually extracted (e.g. `electron` written alongside a `darwin`/`win32` build). Check `ELECTRON_INSTALL_PLATFORM` first, matching the resolution used for `downloadArtifact`. Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

…51370) * fix: honor `ELECTRON_INSTALL_PLATFORM` in `getPlatformPath` (#51029) The postinstall script resolves two things from the target platform: 1. Which artifact to download, via `downloadArtifact({ platform, ... })`. Since #49981, `platform` is derived from `ELECTRON_INSTALL_PLATFORM || npm_config_platform || process.platform`. 2. Which executable path to use for the `isInstalled()` cache check and for the `path.txt` marker written after extraction, via `getPlatformPath()`. `getPlatformPath()` was not updated with the rest of that change and still falls back to `npm_config_platform || os.platform()` only. As a result, passing `ELECTRON_INSTALL_PLATFORM` (as documented in `docs/tutorial/installation.md`) causes the two to disagree: the download fetches the requested platform's zip, but `path.txt` and the path sanity check are written against the host platform's executable name. That in turn makes `isInstalled()` always return `false` on subsequent runs (forcing redundant re-downloads) and makes the executable path recorded in `path.txt` wrong for the artifact that was actually extracted (e.g. `electron` written alongside a `darwin`/`win32` build). Check `ELECTRON_INSTALL_PLATFORM` first, matching the resolution used for `downloadArtifact`. Signed-off-by: Asish Kumar <officialasishkumar@gmail.com> * run oxfmt --------- Signed-off-by: Asish Kumar <officialasishkumar@gmail.com> Co-authored-by: Asish Kumar <87874775+officialasishkumar@users.noreply.github.com> Co-authored-by: Keeley Hammond <vertedinde@electronjs.org>

feat: add ELECTRON_INSTALL_ env vars

ef089d1

electron-cation Bot added the new-pr 🌱 PR opened recently label Feb 28, 2026

erickzhao added no-backport semver/minor backwards-compatible functionality labels Feb 28, 2026

erickzhao marked this pull request as ready for review March 2, 2026 19:00

erickzhao requested a review from a team as a code owner March 2, 2026 19:00

electron-cation Bot added the api-review/requested 🗳 label Mar 2, 2026

VerteDinde approved these changes Mar 2, 2026

View reviewed changes

jkleinsc requested changes Mar 2, 2026

View reviewed changes

erickzhao added 2 commits March 6, 2026 16:02

Merge branch 'main' into electron_install_env_var

1d3a211

add tip for available arches

ce128c2

erickzhao requested a review from jkleinsc March 7, 2026 01:12

erickzhao added target/41-x-y PR should also be added to the "41-x-y" branch. no-backport and removed no-backport target/41-x-y PR should also be added to the "41-x-y" branch. labels Mar 9, 2026

jkleinsc reviewed Mar 9, 2026

View reviewed changes

Comment thread docs/tutorial/installation.md

erickzhao added 2 commits March 9, 2026 15:44

clarify!

afad4a9

use arm instead of armv7l

6535778

jkleinsc approved these changes Mar 10, 2026

View reviewed changes

codebytere approved these changes Mar 12, 2026

View reviewed changes

codebytere merged commit 313e501 into electron:main Mar 12, 2026
97 of 102 checks passed

This was referenced Apr 13, 2026

npm/install.js: getPlatformPath ignores documented ELECTRON_INSTALL_PLATFORM env var #51027

Closed

fix: honor ELECTRON_INSTALL_PLATFORM in getPlatformPath #51029

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add `ELECTRON_INSTALL_` env vars#49981

feat: add `ELECTRON_INSTALL_` env vars#49981
codebytere merged 5 commits into
electron:mainfrom
erickzhao:electron_install_env_var

erickzhao commented Feb 28, 2026

Uh oh!

VerteDinde left a comment

Uh oh!

jkleinsc left a comment

Uh oh!

jkleinsc Mar 2, 2026

Uh oh!

erickzhao Mar 7, 2026

Uh oh!

Uh oh!

jkleinsc left a comment

Uh oh!

codebytere left a comment

Uh oh!

Uh oh!

release-clerk Bot commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

erickzhao commented Feb 28, 2026

Description of Change

Checklist

Release Notes

Uh oh!

VerteDinde left a comment

Choose a reason for hiding this comment

Uh oh!

jkleinsc left a comment

Choose a reason for hiding this comment

Uh oh!

jkleinsc Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

erickzhao Mar 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jkleinsc left a comment

Choose a reason for hiding this comment

Uh oh!

codebytere left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

release-clerk Bot commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants