Current state of Sentry sourcemap uploading with EAS Update

I am trying to determine the current state of support for uploading sourcemaps to Sentry for EAS OTA updates. I’m getting Sentry errors for updated clients, however the backtrace is basically all “Unknown” for the JavaScript/Hermes/updated code.

It appears that the EAS CLI was updated in [eas-cli] Invoke export with sourcemaps on update by kbrandwijk · Pull Request #1228 · expo/eas-cli · GitHub (and I have confirmed I’m running 2.8.0, which includes this) but the note in the PR states that additional work needs to be done in other tools to complete this. (See also related forum post, How to get source map files created during eas update - #2 by wkozyra)

I think that refers to Expo export does not support uploading of sourcemaps to sentry · Issue #298 · expo/expo-cli · GitHub but I’m not entirely clear on that.

Related, I think this is an opportunity to improve Using Sentry - Expo Documentation to make it clearer how Updates interacts with Sentry sourcemaps.

The existing docs indicate that you could swap out postPublish for postExport in the case of hosting your own updates… is this more or less what we’ll be doing for Expo-hosted updates anyway, since all the bundling is done locally?

The good news is, both expo-updates and sentry-expo have recently been updated to enable you to use Sentry with EAS Update on SDK 47. This means that you can upload the sourcemaps that eas update generates to Sentry, and when an exception occurs running an update, it will associate associate it with your update, and your sourcemaps.

Additions the docs are in flight here: Update Sentry docs for EAS Update compatibility by kbrandwijk · Pull Request #19753 · expo/expo · GitHub that describe the process and the configuration.

Let me know if you run into any question or issues!


Thanks. The follow-up steps appear to me to be relatively straightforward to automate. (IOW, it seems that automation is likely already being done in some way by EAS build servers?)

Would the appropriate place for such automation be the sentry-expo package itself?

The recommended manual steps in the PR seem to be a variation on the themes in sentry-expo/upload-sourcemaps.js at main · expo/sentry-expo · GitHub

If the PR is a better place to ask this question I’m happy to switch over to there. I wouldn’t want to block the docs getting updated (since that’s kinda how I ended up asking the question here in the first place) but I can see a relatively straightforward path to making this auto-magical on the client side?

tl;dr: Is there a reason why this must be/should be a manual process?

It’s a process, like you said, that’s relatively easy to automate. That’s why our first priority was to provide the building blocks to make the process work end-to-end, which included properly identifying an update vs a build, and correctly handling the defaults in sentry-expo. With minimal manual steps, which can easily be put in a script, you can start using it today, if we had spent more time up front doing something similar to the old hooks and scripts, you wouldn’t have a solution that you can start using today.

It’s not unimaginable that we will iterate further on this in the (near) future though, and make this more of a plug-and-play process.

1 Like

Thank you @kbrandwijk. The great answers and support from the Expo team are one reason I’m more than happy to pay for EAS every month.

1 Like

@kbrandwijk Opened Clarify behavior of versions in context of EAS Update with some follow-up notes/questions after reading the updated documentation.

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.