[Feature Request]: use single directory for the chromium engine

[DumbGameMaker]

Preflight Checklist

I have read the Contributing Guidelines for this project.
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Electron apps come bundled with chromium for the browser engine. That's fine, but when you have multiple electron apps (i. e. vscode + discord + teams) you are installing duplicates of chromium.

Proposed Solution

when you first launch an electron app, it will check a directory (say, /Users/username/Application\ Support/electron/chromium) for chromium. if it is not found, it will download and install it. if it is found, it will use that.

Alternatives Considered

you could also compile the webapp from javascript to the machine code and eliminate the need for a browser engine entirely, but that would be very hard.

Additional Information

n/a

[pushkin-]

This is basically this issue I believe

[DumbGameMaker]

i guess it is similar but this one talks about installing a single chromium installation, the other one is about asar

[Prinzhorn]

What is the motivation? I think the only benefit is saving disk storage and the time it takes to download (in the best-case. In the worst case the user needs to wait even longer to download Chromium after they've already downloaded your app). Here is a list of things that make this a hard problem to solve, there are likely dozens more:

1. If I ship an Electron app it has been tested with a very specific Electron version. It might use 12.0.2 (Chromium 89.0.4389.90) and might break with 12.0.1 (89.0.4389.82) because it requires a fix that was made. This means it is impossible that two Electron apps in the wild are compatible. They have different release schedules and would never use the same Electron/Chromium. Even for Java Apps it is not unheard of that they ship with the entire JRE to ensure the app works as expected / tested.
2. Native dependencies are compiled against a specific version of Node.js/Electron, similar to 1. this means guaranteeing compatibility is hard
3. "if it is not found, it will download and install it." Download from where? Distribution is the responsibility of the application vendors (Discord etc.). This would also require signing and checksums and whatnot. Otherwise if App1 would decide it needs to download Chromium because it is not already installed then it could download a version that is backdoored. So if you install App2 later it would use the backdoored Chromium.
4. "it will check a directory" this would need to be user configurable. But where would this be configured so that every app finds the installation and that across different operating systems?
5. What about uninstalling? We'd need to keep a transactional list of all Electron applications so that if you uninstall one we know it is safe to also remove the Chromium.

Apart from that it's more complicated than:

Electron apps come bundled with chromium for the browser engine

It's not literally Chromium. It's ripped apart, stripped down and duct-taped to Node.js. As far as I understand.

There are projects such as https://github.com/zserge/lorca that literally use an existing Chrome installation. But this sounds like a maintenance nightmare when you don't know what your users actually run.

Don't get me wrong, I like the general idea. But I don't think this is practical at all. And I think it doesn't belong here (the Electron repo) but to some of the repos that are distribution-related such as forge and builder.

[Prinzhorn]

i guess it is similar but this one talks about installing a single chromium installation, the other one is about asar

#673 does contain some interesting hints though such as https://www.npmjs.com/package/electron-global

[malept]

And I think it doesn't belong here (the Electron repo) but to some of the repos that are distribution-related such as forge and builder.

Please do not file this issue into the Electron Forge issue tracker. I will basically immediately close it as "won't fix" because this is not something that Electron Forge can solve.

---

I'm closing this bug since it's effectively a duplicate.

Duplicate of #673