[Electron] mediainfo.js fails to load WASM after packaging – "both async and sync fetching failed"

[gubeils]

Bug Description

In development mode, mediainfo.js works fine in my Electron project. However, after packaging the app as an .exe using Electron v33.2.1 and esbuild v0.20.0, the app fails to load the .wasm file, even though the path to it is correct and the file exists. A custom locateFile function is used to load the .wasm file from process.resourcesPath in production. The log shows the correct path to the .wasm file, but the app still fails to load it.

Steps to Reproduce

1、Create an Electron app using "electron": "33.2.1" and "esbuild": "^0.20.0". 2、Install and configure mediainfo.js with the following code:

const mediainfo = await mediaInfoFactory({
  locateFile: (path: string, prefix: string) => {
    if (process.env.NODE_ENV === 'development') {
      return `${prefix}${path}`;
    }
    const wasmPath = require('path').join(process.resourcesPath, path);
    console.log('Loading WASM from:', wasmPath);
    return wasmPath;
  }
});

3、In package.json, configure extraResources for electron-builder to include the .wasm file: "build": { "extraResources": [ { "from": "node_modules/mediainfo.js/dist/MediaInfoModule.wasm", "to": "./" } ] }

4、Run the packaged .exe

Expected Behavior

Actual Behavior

failed to asynchronously prepare wasm: both async and sync fetching of the wasm failed Aborted(both async and sync fetching of the wasm failed)

Environment

mediainfo.js version: 0.3.5 Operating System: Windows 11 Electron: 33.2.1 esbuild: ^0.20.0 Node.js: v18.16.0

Additional Information

This only happens in the packaged version (production mode).

[gubeils]

I also tried some alternative approaches based on suggestions from ChatGPT and Gemini, such as using wasmBinary or wasmData to load the .wasm file manually. For example:

const wasmBase64 = fs.readFileSync(wasmPath).toString('base64');
const wasmBuffer = Buffer.from(wasmBase64, 'base64');

const mediainfo = await mediaInfoFactory({
  wasmBinary: wasmBuffer
});

But this led to the following TypeScript error:

TS2353: Object literal may only specify known properties, and 'wasmData' does not exist in type 'MediaInfoFactoryOptions<"object">'.

I also reviewed the mediainfo.js source code and could not find any documentation or implementation that supports wasmBinary or wasmData in the factory options. So it seems these fields are not actually available or supported.

[xeoshow]

I also met the similar problem, locateFile just does not work ...

[buzz]

This is more a question regarding a Electron-specific packaging/loading issue than with mediainfo.js, I'm afraid. For "how-to" questions, please use Stack Overflow (tagged with mediainfo.js) instead of the issue tracker. This helps keep the tracker focused on confirmed bugs and feature requests.

locateFile works as intended. It is really just passed as-is to emscripten's Module object after all. Its task is to return a proper URL/file path, but it has no knowledge about the specific environment you're running in. That is your responsibility.

The error both async and sync fetching of the wasm failed indicates the WASM is being loaded in the browser/renderer process where:

• fetch() can't access raw filesystem paths
• file:// URLs are blocked by security restrictions

So, the solution is to load mediainfo.js inside the Electron main process (Node.js environment) and expose it using some Electron-specific means using window.ipcRenderer.invoke('getMediaInfo') or similar.

TS2353: Object literal may only specify known properties, and 'wasmData' does not exist in type 'MediaInfoFactoryOptions<"object">'.

There is no such option on MediaInfoFactory.

Never trust LLMs.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[zolero]

I'm also stuck here... is there anyone still maintining this library?

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.