Resolve source lines for code shipped in electron.asar

[timfish]

Sources from the built in Electron JavaScript code cannot be uploaded using sentry-cli as they come supplied in an electron.asar archive. This means they can't be displayed in stacktraces:

This could be fixed by:

• Using raven-node code to include adjacent lines in error events
• Add support to sentry-cli or sentry-wizard to read source files from inside asar archives 🤔
• ❓

[aguynamedben]

I noticed this in the docs:

Known Issue

Sentry does not show source code context alongside stack traces in renderer crashes. This is a known issue and will be fixed in a future SDK update.

Does anybody have any good ideas for a workaround? I'm tinkering with raven-js and sentry-cli trying to upload source maps, I haven't gotten it right yet.

I noticed a very popular Electron app ships with the source inside their ASAR package unminified... I'm wondering if there's just not yet a good option for catching/reporting exceptions of a shipped ASAR Electron package.

Any ideas?

[aguynamedben]

I also asked about this in a popular electron boilerplate repo: electron-react-boilerplate/electron-react-boilerplate#1560

The core of the difficulty in my project, which is based on that boilerplate, revolves around these facts:

• Source maps are produced in app/dist/*.map. Webpack minifies/uglifies the JavaScript during the build.
• sentry-cli doesn't seem to have easy ways to differentiate between environment or multiple .env/rc config files
• electron-builder packages Electron apps into an ASAR archive that deploys to the user's machine, this makes it weird to set the path setting in sentry-cli. The path of the ASAR archive probably changes between macOS and Windows clients, too.
• Lots of actual app logic (i.e. UI, React, Redux, etc.) is in the renderer process, so that's the most important area for error reporting to work.

I'm happy to dig into this more if it helps y'all figure this out. I would say a great real-world proof point for this repo would be if you could submit a PR to the electron-react-boilerplate project. It would get Sentry customers via (8k+ stars) and provide a valuable guide of how electron-builder, Webpack, Electron, and Sentry can be used together.

[aguynamedben]

I made some headway doing this with sentry-cli:

Sequence!ben:/Users/ben/code/tesla$ ./node_modules/.bin/sentry-cli releases files 1.1.20 upload-sourcemaps app/dist --url-prefix 'file:///Applications/Command%20E.app/Contents/Resources/app.asar/dist/' --rewrite --strip-common-prefix
> Analyzing 3 sources
> Rewriting sources
> Adding source map references
> Uploading source maps for release 1.1.20

Source Map Upload Report
  Minified Scripts
    file:///Applications/Command%20E.app/Contents/Resources/app.asar/dist/renderer.prod.js (sourcemap at renderer.prod.js.map)
  Source Maps
    file:///Applications/Command%20E.app/Contents/Resources/app.asar/dist/renderer.prod.js.map
    file:///Applications/Command%20E.app/Contents/Resources/app.asar/dist/style.css.map
./node_modules/.bin/sentry-cli releases files 1.1.20 upload-sourcemaps       1.99s user 0.36s system 12% cpu 18.488 total

I have to strip and rewrite the path that the end-user will have the app installed at. I got the path by triggering an error in a production build of my app, observing the error notice in the Sentry error (something like "The file file:///Applications/Command%20E.app/Contents/Resources/app.asar/dist/renderer.prod.js.map could not be retrieved")

I guess I will have to use sentry-cli to upload source maps multiple times, one for each client path my app could be installed in. I.e. on Windows that error will probably report as C:\Program Files\Whatever, so I will probably have to upload the same source map files to Sentry multiple times to cover all the possible places a user might have installed my app.

It would be nice if raven-js (or the future) allowed me to strip the path as the error is sent to Sentry. Is that something that has been considered before?

[timfish]

Hi @aguynamedben,

This issues is specifically about getting source lines files from electron.asar which comes prepackaged.
For your own code you should be uploading sourcemaps from before the packaging step.

You'll need to call sentry-cli something like this:

sentry-cli releases files RELEASE upload-sourcemaps dist/ --url-prefix ~/dist/

In the Sentry UI under release artifacts you'll see the uploaded files as:

~/dist/renderer.prod.js.map
~/dist/renderer.prod.js

sentry-electron already handles path normalisation so an error in renderer.prod.js will be reported in app:///dist/renderer.prod.js which will pick up the above sourcemaps.

[aguynamedben]

@timfish Ahhh, that makes sense. Thanks for the feedback, I'll give it a try today/tonight. Also the "Known Issue" I mentioned from the docs appears to be about crashes in the renderer process, but I'm guessing source maps works for JavaScript errors in the renderer process, which is what I'm mostly interested in. Thanks.

[jtbandes]

sentry-electron already handles path normalisation so an error in renderer.prod.js will be reported in app:///dist/renderer.prod.js which will pick up the above sourcemaps.

Is this still the case? I am getting stack traces with files that look like file:///Applications/MyApp.app/Contents/Resources/app.asar/...foo.js, it does not seem like the NormalizePathsIntegration is working (I am using the default integrations except for Breadcrumbs). Any advice on how to debug this?

[timfish]

@jtbandes if you could open a new bug issue with a reproduction I will look into this. Our tests do test path normalisation across all operating systems but we don't can't test installed apps so maybe there's a case where it's not working.

[jtbandes]

Thanks for the quick reply. Actually, it seems like this was caused by this problem, where we were attempting to use Sentry.init({enabled: false}) and then enable it later. This caused integrations to never be set up.