Mask stack trace in Electron renderer process

[dsanders11]

First off, fantastic project, it was getting to be a real headache to have to use require() in Electron code, and this project provides a much cleaner solution than running everything through webpack.

I have noticed that any errors I get in the DevTools for an Electron window unfortunately don't have an easily visible stacktrace, instead showing everything coming from esm.js.

With some more digging, I found that the error does have the stack property which includes the filename the error actually originated in.

Is there anything this project can do out-of-the-box to make these errors nicer? I know it's a more node focused project, but it is very useful for Electron.

Here's a hack I put in place for my own purposes to get the filename, using the error event on window which will fire for any uncaught errors.

window.addEventListener('error', event => {
    if (event.filename.endsWith('esm.js') {
        console.error(event.error.stack);
        return true;
    }
})

This is what it would output for the above:

file:///Users/dsanders/GitHub/my-project/my-file.js:191
            await foo()
            ^

SyntaxError: await is only valid in async function
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:704:10)

[jdalton]

Hi @dsanders11!

Could you create a sample repo for me to check out. We do mask stack traces to remove the esm bits so I'm guessing in this case we missed a spot (though there are places we could do better still).

[dsanders11]

@jdalton, sure. I just made a fork of standard-things/electron-quick-start and made a branch which added invalid code, can be found here. The error is just like the one in my original screenshot.

[jdalton]

Okay so at a glance, I haven't run it yet, the error is in the renderer process. Is that correct?

[dsanders11]

@jdalton, yes, correct. It's visible in the DevTools for the renderer process.

[jdalton]

Ah nice! Yes, we currently aren't masking stack traces there, but we should be able to. I'm a talk on esm at the Electron Covalence conference Jan 16 so I'll try to have this added by then 😄

[spiritwindy]

electron:: node::

export default class CanvasNest {

  static version = __VERSION__;
}

@jdalton

[spiritwindy]

I am learning design patterns,and don't understand why so many call stacks are needed ?

[jdalton]

Hi @spitWind!

The Node module pipeline is already pretty involved. When you throw on top of that parsing and runtime instrumentation there can be more calls in the stack.