Cannot get electron.remote.require to work

[michelwilson]

I'm trying to get an angularjs-app, which I package with electron, to play together with karma-electron. Previously we used PhantomJS, but I would like to move away from this. The problem is that in a couple of places I have a require('electron').remote.require('./main.js') to get access to some Node stuff from within the renderer process. I cannot seem to get this to work. Using the full path of main.js makes it work, but that is (obviously) undesirable.
I have set __filenameOverride to the location of index.html and loadScriptsViaRequire is set to true. Doesn't seem to make a difference. Clearly, the require is looking in the wrong place for my script (it's in the same directory as index.html). What magic is required to get it working? Issue #11 seems to suggest that it should just work, but doesn't provide me with the detail to get it working in my case...

[michelwilson]

It seems that remote.require is looking in node_modules/karma-electron/lib for ./main.js, so apparently it is using the cwd of the launcher to look for modules. __filenameOverride seems to refer to the normal require, it isn't picked up by the remote.require.

[twolfson]

I've got a few questions:

• Can you verify there's no bundler being used that might affect require? (e.g. browserify, webpack)
• What's the error message you're receiving?
• Would it be possible to get a minimal test case reproducing this issue?

[michelwilson]

I've tried to create an example which is as minimal as possible (not easy), I've uploaded it to https://github.com/michelwilson/karma-electron-minimal-example. The uploaded version works in karma-electron, do a npm install; bower install; karma start to make it go. Comment out src/script.js:4 and comment src/script.js:6 to break it. The working version doesn't work when you do a electron ..

The error I get is:

Electron 1.7.10 (Node 7.9.0) ERROR
  Uncaught Error: Cannot find module './main.js'
  Error: Cannot find module './main.js'
      at Module._resolveFilename (module.js:470:15)
      at Function.Module._resolveFilename (/XXX/minimal/node_modules/electron/dist/resources/electron.asar/common/reset-search-paths.js:35:12)
      at Function.Module._load (module.js:418:25)
      at Module.require (module.js:498:17)
      at EventEmitter.<anonymous> (/XXX/minimal/node_modules/electron/dist/resources/electron.asar/browser/rpc-server.js:263:70)
      at emitTwo (events.js:106:13)
      at EventEmitter.emit (events.js:194:7)
      at WebContents.<anonymous> (/XXX/minimal/node_modules/electron/dist/resources/electron.asar/browser/api/web-contents.js:256:13)
      at emitTwo (events.js:106:13)
      at WebContents.emit (events.js:194:7)
  at /XXX/minimal/node_modules/electron/dist/resources/electron.asar/renderer/api/remote.js:234

[twolfson]

Great, that helped a bunch! Here's what the issues I found:

• We aren't preprocessing src/*.js which is causing __filename and __dirname to be set as the Electron index.html
  • Once this was resolved and client.loadScriptsViaRequire was set back to true, require('../main.js') started working from the renderer (i.e. require, not electron.remote.require)
• This library mostly targets renderer only testing. As a result, the require('electron').remote path issue was unexpected
• What is happening: electron.remote.require is resolving from the remote context, meaning it's resolving from the main file of karma-electron (i.e. node_modules/karma-electron/lib/electron-launcher.js)
  • One workaround is to use require(__dirname + '/../main.js')
  • For a more permanent fix though, I suggest using our launcher require option. Documented here:
    • https://github.com/twolfson/karma-electron/tree/5.2.2#launcher-configuration

To summarize, the following fixes should resolve everything but we recommend the launcher require option instead of electron.remote.require:

karma.conf.js:

// ...
        preprocessors: {
            'src/**/*.js': ['electron'],
            'test/**/*.js': ['electron']
        },
        client: {
            useIframe: false,
            loadScriptsViaRequire: true
        },

// ...

script.js:

// ...
node_script = require('electron').remote.require(__dirname + '/../main.js');
// ...

[michelwilson]

Ah that gives some insight. I've got the minimal example working, now. To get the actual application to work, a bit more is required, as the __dirname trick doesn't seem to work there ... in karma-electron, __dirname refers to the directory of script.js, in electron itself it points to the directory of index.html.

I am not sure what use the launcher require option has. If I use it to require the main Electron script, this seems to start the application, in parallel with the test. Certainly not what I wanted to achieve ;)

[michelwilson]

Well, I don't fully understand why, but I got things working. For anyone encountering similar problems (you never know, and I hate finding problems without solutions ;)):

• I've disabled loadScriptsViaRequire
• __filenameOverride is set to the correct location of index.html (the one in the dev output directory, in my case
• this can be checked by printing __dirname from the script in which you want to remote.require something, very useful!
• and finally, this allows you to do remote.require(__dirname + '/something.js').

No idea if this is the 'right' way, but it makes it work for me :) Thanks for the assistance!

[twolfson]

Glad to hear we got it working. If you'd like, I can help direct you in the direction with respect to main.js. Could you provide more context on why you need to load main.js?

[michelwilson]

In case of the real application, main.js exposes certain functionality that can only be handled outside of the renderer process: sending a UDP broadcast for server discovery. The reason for using karma-electron is to build midway tests at the frontend level of the stack, which talk to an actual backend. This gets us three things: midway tests of the frontend code, tests of the protocol between frontend and backend, and integration tests for the backend. Downside is of course that any test failures pose an interesting puzzle ;)
Anyway: it seems to be working, I can call frontend service layer functions, that call all the way into the backend, so I'm happy.

[twolfson]

Cool, thanks for the info. Here's a few options:

• Break out UDP connection logic into its own file (maybe a client). Then load that into main.js and in testing, load only that file (or maybe a test/karma-require.js which loads it)
• Move to contract-based fixture testing instead of using a live server
  • This is preferable due to (1) faster test runs and (2) reusable pattern with 3rd party services which can have downtime
  • This would mean generating expected request/response transmissions in 1 location and reusing them in your tests
  • For me, I've typically generated those in the server tests with either fs.writeFileSync or an assertion that the request/response are 1:1 with whatever is on disk. Then, I'd set up a mock using those fixtures in the renderer tests
  • Here's an example with HTTP fixtures
    • https://github.com/twolfson/multi-image-mergetool/blob/1.32.1/test/server/update-image-set-filepath-show.js#L52-L58
    • https://github.com/twolfson/multi-image-mergetool/blob/1.32.1/test/browser/application-update-similar-images.js#L21
    • https://github.com/twolfson/multi-image-mergetool/blob/1.32.1/test/test-files/http-responses/xhr.js
• Use a tool like spectron which is better equipped for full application testing
  • https://github.com/electron/spectron
  • Although, I'm guessing you already understand the tradeoff you've made by using Karma (less likely to break, easier to debug)

[michelwilson]

Interesting reading, thanks! I particularly like the idea of contract-based fixtures, as this circumvents the problem of not really testing the API by explicitly defining it. Even gives you a form of documentation for the API :) Thanks! I believe that I'll continue to use the current approach, due to time/budget constraints, unfortuntely. However, there'll always be future projects :)