Allow to run Electron apps without ASAR support

[bpasero]

Since VS Code is not leveraging ASAR at all, we would like to completely run without ASAR by setting process.noAsar = true;

However, it seems that electron.asar is always being looked for on startup of an Electron app so I cannot just go and unzip this file and put it somewhere (

electron/atom/common/node_bindings.cc

Line 164 in 0c53317

resources_path.Append(FILE_PATH_LITERAL("electron.asar"))

is suspicious).

Any reason behind this? Would it be possible to first see if the electron.asar exists at all?

[miniak]

Why don't you use asar?

[baconbrad]

Why don't you use asar?

A big downfall to an ASAR file is that once it is in use it is basically write protected and cannot be deleted/modified. Which is documented in Code's issue manager. It might be unrelated but they were unhappy with the modification to the FS module when ASAR was first introduced.

[anaisbetts]

Uhhhh why would you want to be rewriting your own app's code at runtime

[bpasero]

We are not leveraging ASAR because most of our code is AMD and bundled into single large JS files via build step. For node_modules we are investigating into solutions like https://webpack.github.io/

Since we are a code editor with a file explorer, it is likely that a user might have ASAR files in a workspace. We already have to do some modifications to ensure we are not accidentally showing the ASAR file as a folder that the user can open by patching fs with original-fs. There are more tricks we have to do in other areas.

Ideally we could just turn off ASAR globally and this is what this request is about.

[baconbrad]

Uhhhh why would you want to be rewriting your own app's code at runtime

In the case of VS Code it is not a matter of modifying the app.asar but other third party ASARs where the end user expects to be able to delete or modify an ASAR file.

[anaisbetts]

Dunno, can you submit a PR to this effect @bpasero?

[cookiengineer]

Why don't you use asar?

Basically every single issue opened in the asar repository is a valid reason to skip the format. It's the definition of reinventing a binary concat format that is error prone, untested and does not work for everything non-UTF8.

So why not just use tar / bsdtar with a simple electron.json file (as header replacement) inside?

Then packages could be built even with a bash script, will be possible on every single machine on the planet, is failsafe and does not lock out japanese or chinese users (or every other language that is not English and UTF-8).

A whole new world opened by not requiring electron-packager or the node/npm world, helping people from other areas; just by not using an ASAR archive and instead using a zip or tar archive.

[anaisbetts]

@cookiengineer but like, maybe just use UTF-8 and ASAR?

[cookiengineer]

@paulcbetts C'mon you can't be serious? ASAR has exactly zero specifications. The README is a joke and has basically no documentation at all. No examples and nothing to test against.

You are currently ignoring the reason why RFCs and the IETF exists. Where's the spec for ASAR then? How can people implement it? Where are the tests? Is there a plan to make an RFC for the ASAR archive format so that the ASAR issues can be resolved?

[miniak]

@cookiengineer Since when is having non-ascii filenames a good idea?

[cookiengineer]

@miniak: Since there are people existing that do not speak English as a native language? Like literally, most of the people on the planet?

Clarification: Don't get me wrong, I would be in for ASAR if it would be standardized and failsafe. But, as there are 30 year old alternatives with identical advantages and/or drawbacks, there's literally no reason to use a solution that introduces far more complexity than reasonable features.

Compare ASAR it with gzip, tar or even zip - all tested, standardized, open source, available everywhere, in all programming languages, on all systems, allowing all a superset of features that ASAR has.

[miniak]

@cookiengineer Having the contents of the file in any language does not mean that the filename has to be localized. And as far as I know, UTF-8 can handle any language. And when only using the ASCII subset, you don't have to pay the price as with UTF-16.

[miniak]

@cookiengineer Also tar is an ancient format originally designed for tape archives with 512 byte blocks. Why not create something new considering today's requirements.

[cookiengineer]

@miniak If you want to go the new better-invention route, why not use brotli or zopfli or gzip container? All of them have RFCs and are properly specified.

Your format is incomparable to even gzip deflate. It's literally just a concat, so you can't argue with tar being legacy here - because tar has the identical feature set AND is cross-platform, available everywhere. ASAR isn't and is not supported by any today's archive GUI tools and probably never will if the spec is missing.

Personally I think the "what should replace ASAR" discussion is off-topic. I would prefer a format that is cross-platform and can be understood by non-developers, allowing them to unpack and pack it with their GUI tools. A format that is specified and works everywhere natively in the OS. Not some custom format that has zero support for everything and introduces no features and is no invention.

[miniak]

@cookiengineer it's not my format :) let's agree to disagree, I don't want to argue.

[YurySolovyov]

I'd say we should rather fix asar and how electron handles it.
@paulcbetts

Uhhhh why would you want to be rewriting your own app's code at runtime

Well, to have browser-like F5-fix-F5 experience

[YurySolovyov]

@cookiengineer you can find some reasoning behind asar here

[baconbrad]

Correct me if I am wrong but ASAR is completely optional in use. If you don't like it you don't have to use it. In the case of this issue Microsoft VS Code doesn't use an ASAR but the code in Electron still treats ASAR files like an archive. As a result their editor does too. Whereas they want them to be treated like any other editor would treat them.

And the idea of ASAR wasn't to reinvent an archive format but to create a new one that met the purposes specific to Electron. And other archive formats didn't meet this. I think NW.js is evidence that using a widely used archive format (zip) just doesn't work out especially with bigger and more complex programs.

[bpasero]

Another problem is that if you fork a process from electron, this process also gets ASAR support without asking for it. In our case we spawn node processes from electron (we do not ship our own node.js executable) for extensions that run in VS Code. These extensions use the fs module as usual but run into the ASAR issues as well. The only workaround is to ask each extension to set process.noAsar = true;in their start script which is bad because this couples extensions to the runtime (electron).

[bpasero]

Maybe asar.js could also check for an environment variable to be defined in addition to process.noAsar (close to

electron/lib/common/asar.js

Line 37 in 932b6dc

if (process.noAsar) {

)? @zcbenz @kevinsawicki would you accept such a PR or do you see issues? This would allow to fork a process where the environment asks to have asar support disabled and does not require the code that gets executed to set it.

[kevinsawicki]

would you accept such a PR or do you see issues? This would allow to fork a process where the environment asks to have asar support disabled and does not require the code that gets executed to set it.

Yeah, an environment variable or command line flag sounds good to me 👍

[bpasero]

@kevinsawicki see #7479

[codebytere]

This has been done, closing!

[elimisteve]

This worked for me: electron-userland/electron-builder#428 (comment)