redundant asar duplicating & faulty packaging with recent updates

[marcelblum]

Waaay back in July of this year I successfully built a universal packaged app of my project on an arm Mac using Electron 13 and the then-latest version of electron-forge via electron-forge package --arch=universal. It neatly included a single app.asar shared by both arches, and a single app.asar.unpacked folder containing various platform-specific binaries for both arches.

Now I've updated to latest Electron 21 and latest Forge, and the packaged app produced by electron-forge package --arch=universal is all borked. It contains an app-arm64.asar and an app-x64.asar which appear to be identical. It also has app-arm64.asar.unpacked and app-x64.asar.unpacked folders which have identical contents - both folders contain binaries for both arches. There is also a tiny app.asar file that contains only 2 files - my app's own package.json along with an index.js which seems to be a renamed has-asar.js. The app itself does not run properly and throws a "file not found" error for my app's index.html (loaded via BrowserWindow.loadFile()) - the error message shows that it is attempting to load from "Contents/Resources/app.asar/src/index.html". I should add that if I run a plain electron-forge package it works fine and creates a perfectly packaged arm-only app.

What am I doing wrong here? Are there some new configuration options necessary to properly build for universal, that perhaps weren't needed 4 months ago, or weren't needed with older Electron versions?

[MarshallOfSound]

Contents/Resources/app.asar/src/index.html

This means you are probably doing path resolution incorrectly. You should ensure all paths are resolved relative to __dirname

What am I doing wrong here? Are there some new configuration options necessary to properly build for universal, that perhaps weren't needed 4 months ago, or weren't needed with older Electron versions?

If your two app's (x64 and arm64) don't generate exactly identical ASAR files we split them and use the entry-asar to dynamically load the right one. If you run with DEBUG=electron-universal you should see a bunch of logs explaining which file has a SHA mismatch. If you can fix the mismatch, it will go back to using a single ASAR

[marcelblum]

thanks @MarshallOfSound for the tip - I used DEBUG=electron-universal and got tons of output (>300 lines) but I can't find anything of note in the logs. No occurrence of "mismatch", "SHA", "node", or any other relevant term I could think of to search for. At one point I see "electron-universal checking asar mode of ..." but it gets cut off by electron-forge status output and there's no further occurrence of "asar". The vast majority of the debug output refers to hashing of hundreds of files in the Frameworks dir. Any further tips on what I'm looking for here?

This means you are probably doing path resolution incorrectly. You should ensure all paths are resolved relative to __dirname

I'm simply calling newWindow.loadFile("src\\index.html"), is that wrong? As I said this works perfectly fine in a single arch package built via electron-forge package (and the same line worked fine in my last successful universal build as well).

[marcelblum]

No help from the debug logs but through process of elimination I was able to isolate the cause of the problem. It was a native module package (uiohook-napi) with an apparently wonky rebuild configuration that was forcing a rebuild for each arch even though prebuilds already exist for both arches. Going to have to look into that further but not an issue with electron universal so closing this issue.

[marcelblum]

In case anyone else reaches here with a similar issue, the native module I was using was in turn using node-gyp-build and prebuildify to load its binary, and something about the configuration was triggering a rebuild when packaging, placing an arch-specific binary in a central folder instead of finding the existing prebuild in an appropriately named folder. This led to electron-universal identifying that resulting build folder as a mismatch between arches which led to the duplicate asars. My workaround was to force no rebuild by using the Forge rebuildConfig option onlyModules.