rfc: lazy electron download, remove postinstall

[MarshallOfSound]

Raising this as an RFC mostly because I want to be sure I haven't missed something obvious but also I don't super have the time to do it so hopefully this sketches out a nice win that someone else can run with.

[reitowo]

I'm in favor of this, developers use pnpm@10+ will default skip running postinstall, and they are aware of this if they choose to upgrade pnpm, and for older developers we can keep the behavior to prevent break workflows. The lazy download could be a additional check if developers doesn't install the binary for whatever reason.

[MarshallOfSound]

The reason I excluded this was consistency, the first question in the bug report shouldn't be "ok so do you have postinstall enabled? oh you don't know? ok are you using pnpm? or yarn > 4.10?". That just doesn't found fun. I think the experience should be consistent across all package managers

[erickzhao]

To me, being able to run npx install-electron on postinstall sounds like a happy workaround for devs who want to still run it that way 👍

[itsananderson]

I wonder if it'd be better to define a bin script in the electron module called install-electron?

This would avoid needing a separate package, and I think it would also simplify the install-electron logic, because now the install-electron script would be inside the electron package, so it wouldn't need to deal with package hoisting or Yarn workspaces or anything, because it would always know exactly where the electron package is installed.

With this approach, people could still run:

npm install electron
npx install-electron

Or run the bin command in their own postinstall:

{
  "scripts": {
    "postinstall": "install-electron"
  }
}

[MarshallOfSound]

To clarify it would be a bin command in the same electron package.

npx runs any bin command, not just package names

[erickzhao]

I wonder if we should still reserve the install-electron package name so people don't run npx install-electron in the wrong dir and run some random untrusted code by accident.

[MarshallOfSound]

Good call, it's mine 😅 we can do what we want with it

[MarshallOfSound]

But also, npx considered harmful. I'd advocate for not documenting it (used in this spec because it's so easy to type lol)

[itsananderson]

One other thing that we may want to call out in the RFC is that usage of ELECTRON_MIRROR (and friends) will change. Previously you would set those variables when running npm install, but now I guess you'd need to set them either when running install-electron or when invoking electron.

There's also ELECTRON_SKIP_BINARY_DOWNLOAD which probably just goes away with this new approach?

[MarshallOfSound]

There's also ELECTRON_SKIP_BINARY_DOWNLOAD which probably just goes away with this new approach?

Yup

One other thing that we may want to call out in the RFC is that usage of ELECTRON_MIRROR (and friends) will change. Previously you would set those variables when running npm install, but now I guess you'd need to set them either when running install-electron or when invoking electron.

Yeah, that should be fairly trivial for folks to update though, just set the env var more globally in CI or locally it's probably already in their zshrc or something anyway and will Just Work

[erickzhao]

RFC LGTM

[itsananderson]

RFC LGTM

[samuelmaddock]

RFC LGTM

Thanks for the great writeup and explainer!

[reitowo]

RFC LGTM

[jkleinsc]

RFC LGTM

[pavelai]

I disable install scripts and install Electron manually. I think the proposed solution has UX/DX which doesn't look friendly or handy for me. For those who disables scripts it's obvious that Electron couldn't be run without extra steps taken, for those who don't nothing should change. So the solution to this problem should be NVM-like util to download and run static assets for the package, something like `@electron/cli. It will be obvious and explicit CLI command call authorized and made willfully by the users

And in my opinion there should be a way to install downloadable assets with package managers and there should be some work done from NPM team to make it work. There is Esbuild package which uses sophisticated optional dependencies to download required binary of esbuild, but for most users it doesn't look reliable enough, because optional is decided as non-mandatory. There should be better, deterministic solution to download such files without the need to install custom utils for any package

In some perfect situation it could work as so:

1. User installs electron package
2. Electron package has dependency @electron/binary
3. Electron binary package has URLs dependency list which refers to the version of software to install for current environment
4. NPM downloads the binary from the provided URL

[erickzhao]

Hey @pavelai, thanks for the feedback!

I disable install scripts and install Electron manually. I think the proposed solution has UX/DX which doesn't look friendly or handy for me. For those who disables scripts it's obvious that Electron couldn't be run without extra steps taken, for those who don't nothing should change.

This isn't mentioned in the RFC but if you disable the download via ELECTRON_SKIP_BINARY_DOWNLOAD env var instead of --ignore-scripts or the equivalent for other package managers, I think your flows would work with minimal disruption.

Do you feel like that'd be a happy solution as long as everything is properly documented?

[pavelai]

@erickzhao Thanks for the reply. I think properly documented solution is always better. But I'd be even more happy to have more predictable options, like CLI tool and/or CLI dialog. For many users it could be unexpected, that in the moment of the first app run they would need to download about two hundreds megabytes of code. I can imagine when it happens in the moment they has low bandwidth if the installation and the first run has delay. But I'm not sure it's a big issue, just should be noted. Any way there should be considered some manual option to make download predictable

As a Mac user I can download and install Electron via browser and put it to Applications folder. Then I would want to run it as a regular Mac application from my project, and for me electron package could be only a thin wrapper. It would work perfectly if Electron Forge could use it too

I could describe requirements to such a software, but it could take some time, maybe day or two. Anyway I believe this feature should not be delivered without an official tool to install electron application manually. Probably wider discussion is needed to make it properly

[reitowo]

I think in most case electron apps to end-user are shipped together with electron binary, and user will not use any command like npm.

Your word's "user" might mean "developer", and also you mentioned "For those who disables scripts it's obvious that Electron couldn't be run without extra steps taken, for those who don't nothing should change.", I think this is true because the author of this RFC writes "Respect ELECTRON_CUSTOM_DIR and other environment variables" when doing the path resolution. Since you've take extra steps like setting a custom electron binary path or something like that, it should be same like your current status. e.g. you may write custom npm commands that runs your custom binary, which doesn't use npx electron at all. If this is not the case, I think use a seperate new command breaks more people's current experience.

[pavelai]

@leitowo thanks for the answer

Let me clarify, I'd like to propose to make the download intentional. For this there should be a prompt dialog in the CLI to notify user about what's going on and how long would it take. In the prefect version there should be a progress shown in console. Currently there is no information about it in the proposal. Am I missing something?

And I'm wondering why don't you consider the Esbuild's option, when there are binaries provided as optional-dependencies? It seems more user friendly and predictable, but it wasn't discussed here

[reitowo]

Yes, the progress bar is mentioned in the RFC.

2. **Modify CLI wrapper** (`cli.js` or equivalent):
   - Check if Electron binary exists at expected path
   - If not present, trigger download before spawning Electron process
   - Show progress indicator during download
   - Handle download errors gracefully with clear error messages

Moving this "lazy" to a seperate binary dependency might breaks many project and expectation that they can run their electron project with npm install electron + npx electron ., everyone needs to run a seperate command or add a seperate deps in that way. There're also some custom logics like proxies, cache, custom location and mirrors needs to be kept supported.

Your suggestions could be supported as a alternative way to install electron binary dependencies, but I think it's also important to keep compatibility.

[pavelai]

@reitowo Thanks for clarification about progress.

Moving this "lazy" to a seperate binary dependency might breaks many project and expectation that they can run their electron project with npm install electron + npx electron.

This should be solved with a check whether the stdin is a TTY or not. This should allow this code to work in CI and other pipelines without changes

I'm still interested to discuss ESBuild solution. It seems like it wasn't discussed at all, but was mentioned in the RFC