remote.require() is relative to electron-forge/lib/cli.js not package.main

[gmaclennan]

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Please describe your issue:

According to the electron docs on remote.require:

Returns any - The object returned by require(module) in the main process. Modules specified by their relative path will resolve relative to the entry point of the main process.

However, when running an app with electron-forge start then remote.require resolves relative to node_modules/electron-forge/lib/cli.js.

This is mentioned in #48 (comment) but the issue is closed.

If this is expected/intended behavior then I suggest that this is documented somewhere, if it is unintended, then we need an open issue to fix it. Happy to update this issue to be either a documentation issue or a bug.

Please provide either a failing minimal testcase (with a link to the code) or detailed steps to
reproduce your problem. Using electron-forge init is a good starting point, if that is not the
source of your problem.

The repo below demonstrates this behavior with a minimal test case showing how the expected use of remote.require fails.

https://github.com/gmaclennan/forge-remote-require-test

[gmaclennan]

Hmm... this definitely seems like a bug. When the app is packaged, then remote.require() is relative to the project root, not the entry point to the main process (because when the app is packaged with electron-forge then the actual entry point is es6-shim.js in the app root).

To reproduce run npm run make in the project linked above (https://github.com/gmaclennan/forge-remote-require-test) and run the app. Neither remote.require works in this scenario.

[MarshallOfSound]

@gmaclennan Could you try applying the patch here electron-userland/electron-compile#274 to your local install of electron-compile and see if it fixes it 👍

FWIW I always recommend using absolute paths for things like this, relative paths are just asking for trouble 😉

[gmaclennan]

hi @MarshallOfSound thank you for looking into this. I get an error require.main.require.resolve is not a function with this patch. FWIW console.log(require.main.require.toString()) gives:

function (path) {
  assert(path, 'missing path');
  assert(typeof path === 'string', 'path must be a string');
  return Module._load(path, this, /* isMain */ false);
}

Using an absolute path would not work for the packaged app - it tries to load the module from outside the app bundle. Absolute paths would also break the app for other collaborators.

[MarshallOfSound]

@gmaclennan
My bad, try the new patch 👍

When I say absolute paths I mean resolve it yourself. I.e. Resolve all paths relative to a known points inside your app path.resolve(__dirname, 'relative/path/to/file')

[gmaclennan]

Hi @MarshallOfSound great stuff, this patch does fix things when running the app with electron-forge start however, the packaged app is still broken - the packaged app tries to require relative to the project root (where es6-shim.js is) rather than relative to the app entry point.

Thanks for the clarification about absolute paths, I am used to using browserify and I forgot I can have variables in require pathnames in electron :)

[MarshallOfSound]

the packaged app tries to require relative to the project root (where es6-shim.js is) rather than relative to the app entry point.

I think that's something we can fix on forges side by simply positioning that shim right next to your actual entry point file 👍 If I get time I'll try work on this some time next week

[MarshallOfSound]

This will be fixed in v6 because electron-compile is not used by default 👍