fix: honor ELECTRON_INSTALL_PLATFORM in getPlatformPath#51029
Merged
jkleinsc merged 1 commit intoApr 28, 2026
Conversation
Contributor
|
For more information on signing commits, see GitHub's documentation on Telling Git about your signing key. |
codebytere
approved these changes
Apr 14, 2026
Member
|
The original PRs are landing in @officialasishkumar you'll need to sign your commits to land a PR in the Electron org. Thanks in advance! |
Member
|
@officialasishkumar looks like all of CI is green except for the "commits need to be signed" check. Can you force-push up the branch with signed commits? |
b352ba7 to
5bfb1b3
Compare
Contributor
Author
|
done |
Member
|
@officialasishkumar you'll need to rebase |
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>
5bfb1b3 to
99d44b7
Compare
Contributor
Author
|
Rebased onto |
jkleinsc
approved these changes
Apr 28, 2026
Member
|
Merging as CI failure unrelated to PR change. |
|
Release Notes Persisted
|
Contributor
|
I was unable to backport this PR to "42-x-y" cleanly; |
Contributor
|
@erickzhao has manually backported this PR to "42-x-y", please check out #51370 |
Member
|
Auto backport failed due to linter changes, created one myself. |
ckerr
pushed a commit
to erickzhao/ericktron
that referenced
this pull request
Apr 30, 2026
…#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>
jkleinsc
pushed a commit
that referenced
this pull request
May 5, 2026
…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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Change
Fixes #51027.
npm/install.jsresolves the target platform in two places and the two disagree when the documentedELECTRON_INSTALL_PLATFORMenv var is used.downloadArtifacthonors the new env var (added in #49981):But
getPlatformPath(), which produces the executable path written topath.txtand compared inisInstalled(), was not updated and still only checksnpm_config_platform. On, for example, a Linux host runningELECTRON_INSTALL_PLATFORM=darwin npm install electron, thedarwinzip is downloaded butpath.txtis written aselectron(the Linux executable name) — so subsequentisInstalled()checks always fail (forcing redundant re-downloads) and any tool readingpath.txtsees the wrong filename for the artifact that was actually extracted.Bring
getPlatformPath()in line with the download resolution by checkingELECTRON_INSTALL_PLATFORMfirst.Checklist
Release Notes
Notes: Fixed
ELECTRON_INSTALL_PLATFORMbeing ignored when resolving the Electron executable path during postinstall, which causedpath.txtto be written for the host platform instead of the requested target and madeisInstalled()always re-download on subsequent installs.