Open bendemboski opened 5 months ago
Hey @bendemboski, I was taking a look at this today and it seems like the repro case happens whenever the x64 and arm64 ASARs diverge.
Converting the asar.js
shim into its ESM equivalent indeed seems to fix the problem on my end.
Don't have time to put up a PR today but this seems to work according to my local testing.
// has-asar.mts
import { app } from 'electron';
import { createRequire } from 'node:module';
import path from 'node:path';
if (process.arch === 'arm64') {
await setPaths('arm64');
} else {
await setPaths('x64');
}
async function setPaths(platform: string) {
// This should return the full path, ending in something like
// Notion.app/Contents/Resources/app.asar
const appPath = app.getAppPath();
const asarFile = `app-${platform}.asar`;
// Maybe we'll handle this in Electron one day
if (path.basename(appPath) === 'app.asar') {
const platformAppPath = path.join(path.dirname(appPath), asarFile);
// This is an undocumented API. It exists.
app.setAppPath(platformAppPath);
}
const require = createRequire(import.meta.url);
process._archPath = require.resolve(`../${asarFile}`);
await import(process._archPath);
}
If have an app whose main process is implemented as ES modules, and when I add a native dependency and don't merge the ASARs, the app fails to run with:
I have worked around it using
patch-package
and replacinghas-asar.js
with ahas-asar.mjs
that looks likeHowever, I'm not sure how to turn this into a general purpose solution because:
src/index.mjs
) and I'm not sure a good way to determine it dynamically.process._archPath
should actually be in this case?