console.log calls from utility process don't work
reproduction steps:
import { utilityProcess } from 'electron'
import log from 'electron-log/main'
import forkPath from './background.js?modulePath'
log.initialize({ spyRendererConsole: true })
log.transports.file.level = 'debug'
log.transports.file.maxSize = 10 * 1024 * 1024 // 10MB
autoUpdater.logger = log
const util = utilityProcess.fork(forkPath)
then running any console calls inside background.js won't call logs in electron log
the fix is
const util = utilityProcess.fork(forkPath, [], { stdio: ['ignore', 'pipe', 'pipe'] })
util.stderr?.on('data', d => log.error('' + d))
util.stdout?.on('data', d => log.log('' + d))
expected fix: read log from electron stdout instead of consolespy? or maybe outline this problem in docs?
[Utility Process]
Data can be returned to the main process for printing through process.parentPort.postMessage
process.parentPort.postMessage({ event: 'LOG', data })
[Main Process]
this.utilityProcess.on('message', (message: any) => {
const { event, data } = message
switch (event) {
case 'LOG':
return console.log(data)
// do something ...
}
})
yes, adn the issue is exactly about not needing custom code for it, just like with the renderer and main processes, also using stdio is way faster than port messages since its not blocking
Currently, I'm considering two options:
- Provide
electron-log/utilitywhich usespostMessageunder the hood - Do not provide built-in support; provide the fix mentioned here as an example
I don't think there are any other universal solutions.
yeah I think adding a chapter about utilityProcess with the fix I provdied above is the best solution, an explanation of why it's required would be decent too I guess, just so it's documented so people don't waste 2h trying to figure out why debugging isn't working lmao
actually adding a way to log the messages from main process would also fix this i guess?
Currently, I'm considering two options:
- Provide
electron-log/utilitywhich usespostMessageunder the hood- Do not provide built-in support; provide the fix mentioned here as an example
It really doesn't matter which, as long as it's documented and the utility messages can be distinct (so I know they're from utility processes) when I'm reading my logs.