Where can I find the logs for my Electron production application?

Question

I created an application with Electron and used Electron-Builder to create the Squirrel installer and update. All this works fine, but it's hard for me to debug the production version of my application.

Are the logs created by console.log written somewhere on disk when using the production version? If so, where can I find them? Or are they all deleted when compiling the executable? Should there be some kind of log file for my application?

I found SquirrelSetupLog in C:\Users\Tieme\AppData\Local\MyApp\SquirrelSetupLog , but this is not enough to debug my production problem.

---

Just stumbled upon electron-log . This may work if regular logs are not actually written to disk somewhere ..

Answer 1

If you mean the console from a web application, then this applies :)

You must make a callback for this to work. Find out more about them here: http://electron.atom.io/docs/api/remote/

Here is a quick example:

In the file next to your electronic main.js named logger.js add this code:

 exports.log = (entry) => { console.log(entry); } 

And then in your web application use this to call the log method callback:

 // This line gets the code from the newly created file logger.js const logger = require('electron').remote.require('./logger'); // This line calls the function exports.log from the logger.js file, but // this happens in the context of the electron app, so from here you can // see it in the console when running the electron app or write to disk. logger.log('Woohoo!'); 

You might also want to take a look at https://www.npmjs.com/package/electron-log for "better" logging and writing to disk. But you always need to use callbacks.

Answer 2

Old question, but I found it convenient to configure this in package.json (this applies to the console from the main process)

  "main": "app/src/main.js", "scripts": { "postinstall": "install-app-deps", "start": "npm install && electron . > /tmp/electron-app.log", "pack": "build --dir", "dist": "build", "dist:win": "build --platform win32", "dist:linux": "build --platform linux" } 

You could work it out a bit, for example, get the path / tmp / from somewhere, but you get the idea :)

I would advise accepting the accepted answer and generally constantly calling “main” from the renderer: the costs of this context change are quite large and can even be huge if you register JSON objects that need to be converted to a string and parsed back to Trip. Your renderer will work with a hand brake!