An update on this: I was forced to compile an Electron-exclusive version of the WASM to include NODEFS (NodeJS File System). This now works fine when the app is run by Electron from the File System: the app can mount the WASM and can read the packaged archive.

HOWEVER; when the app is packaged by Electron Builder, the main app is placed inside an asar archive, and the packaged archive is (intentionally) left outside that archive. Despite multiple attempts to "cross the barrier" by mounting the File System from different directories, so far I have not been able to instruct the WASM to read anything outside of the asar archive. It appears that the "root" of the FS is the top-level directory INSIDE the asar archive. This means I either have to include the ZIM archive inside the asar, which is problematic for large archives, or else I have to ship without asar packing, which is particularly problematic for the portable app (because it takes too long to decompress all the app's files on startup vs decompressing a single asar).

Removing asar packaging doesn't solve the issue. See openzim/javascript-libzim#26 (comment) for more details. It's very odd: the libzim WASM reads the packaged archive perfectly well when running npm start (i.e. with electron runtime), but it fails once the app is packaged.

Some guesses:

• Node integration in the Worker scope doesn't work properly;
• The path to the packaged archive (which is given relatively, so shouldn't be affected), is altered by the directory structure of the packaged app (this is because the error which throws is "there is no such file or directory");
• A race condition (I once thought I saw the NODEFS successfully load inside the packaged app after a long pause, but may have been mistaken).

I guess the second of these is the most likely, but I tried several things to try to understand the directory structure and where root was, and haven't managed to solve it yet.

It was indeed the way the file system paths were being passed to the WASM. I've pushed a fix to #323.