Ejected app + Sentry - Any fool-proof setup?

I’m trying to set up Sentry on an ejected app, but it has been a bit messy so far.

Just using sentry-expo doesn’t track native code errors. react-native-sentry tracks native code but then I don’t have sourcemaps. If I enable sourcemaps on app.json while using react-native-sentry I get an unused release on Sentry i.e. 1.0.1 is the iOS version which is used by react-native-sentry from Info.plist while the sourcemaps step uses releases 1.0.0.randomchars which is read from the app manifest. Any errors are reported on 1.0.1 in this case and 1.0.0.randomchars has the sourcemaps but are unused.

Is there any guide or something that could help me out?

I’m ejected and using Sentry, but just sentry-expo at the moment, so I’m missing native errors. I haven’t tried this yet, but was thinking that maybe the path of least resistance would be to create separate projects in Sentry- one using react-native-sentry (or heck, just plain old Sentry native and link it yourself) just for native errors, and the other using sentry-expo for JS errors. Not perfect, but at least I’d be getting all the errors. Jamming something in the middle of the ExpoKit build process is pretty hairy, but putting something on the end to upload symbols of whatever you need to do to support native error reporting shouldn’t be too bad.

I strongly suspect this all gets a lot more straightforward once the bare workflow fills out, supporting the ExpoKit features that are still missing (like OTA updates). I’m still glad I went with ExpoKit vs. plain old React Native (bare workflow wasn’t even on the horizon when we started, and we’re almost done with this release cycle), but the bits that are tightly coupled to the managed workflow build process can make customization weird sometimes. If you’re really early in your development cycle, you may want to switch to bare. If you need OTA updates, you would have to go without them for a bit, but it sounds like the plan is to release a unimodule for that, so it’ll be there at some point. A bare workflow project in theory makes it possible to use Microsoft CodePush for OTA updates for the time being, as well.

I’ve had to eject on another app and as a js/php dev it was one of the hardest things to do in a while. Is there a way to use expo and sentry without ejecting. Is there some way to hook into the built in error handling to report to sentry? https://docs.expo.io/versions/latest/sdk/error-recovery/

I feel like there has to be somewhere in the js codebase, maybe App.js?

Any ideas how to make this happen? I’ll post back if I figure it out, off to tinker…

I’m not sure we’re talking about the same thing. This post was specifically about using Sentry to catch native errors (e.g., from Java/ Objective-C) in an ejected app, rather than just JavaScript errors. Getting Sentry working in a managed app is quite straightforward, the doc is right here: https://docs.expo.io/guides/using-sentry/#install-and-configure-sentry. And actually, now with the Bare workflow, the Sentry configuration steps pretty much follow the same steps as they would for any mobile app regardless of toolchain, so Sentry picks up native errors as well in the Bare workflow.

At any rate, you could hook something into Error Recovery, probably using the Sentry web SDK, but Error Recovery is reporting the same errors (errors from JavaScript) that sentry-expo is reporting, so just use sentry-expo.

Oh wow you’re right, sorry guys I didn’t mean to hijack the post, thanks for sending me in the right direction.

1 Like