chore(mobile): upload source maps to PostHog on release and OTA builds#84
Open
GSTJ wants to merge 2 commits into
Open
chore(mobile): upload source maps to PostHog on release and OTA builds#84GSTJ wants to merge 2 commits into
GSTJ wants to merge 2 commits into
Conversation
…ve builds Enables readable Release JS stack traces in PostHog error tracking: - metro.config.js now wraps the default config with getPostHogExpoConfig, injecting a debug/chunk id into every JS bundle (native builds and OTA exports alike) so uploaded sourcemaps can be matched back to the exact bundle a crash came from. - app.config.ts conditionally adds the posthog-react-native/expo plugin, which wires posthog-cli into the generated Xcode "Bundle React Native code and images" build phase and the Android Gradle release bundle task. Gated on POSTHOG_CLI_API_KEY being present so a bare local `expo prebuild`/`run:ios`/`run:android` never gets the upload step injected -- only EAS-configured builds (which pull that key from the EAS "production" environment) activate it. - scripts/upload-posthog-sourcemaps-ota.sh handles the other half: `eas update` OTA bundles have no build phase to hook into, so this re-exports the JS with sourcemaps and uploads them via `posthog-cli hermes upload` separately. Also guarded on POSTHOG_CLI_API_KEY, so it's a silent no-op without credentials. Verified locally: a Release iOS simulator build successfully created a PostHog release and uploaded its sourcemap (server confirmed via posthog-cli's own output), and the OTA script independently exported + uploaded sourcemaps for both platforms against the real PostHog project.
deploy-mobile.yml's `eas update` step publishes the OTA bundle but never uploaded sourcemaps anywhere -- the stale TODO here claimed PostHog RN had no build-time upload CLI, which is no longer true (posthog-cli's `hermes upload` command covers this). Runs the new sourcemaps:upload:ota script through `eas env:exec production`, which pulls POSTHOG_CLI_API_KEY/HOST/PROJECT_ID from the EAS "production" environment (the key is stored there as "sensitive", not "secret", so it's readable by the CLI outside the builder) and injects them into the script's shell env.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Production JS stack traces in PostHog error tracking become readable: source maps now upload automatically on native release builds and OTA updates.
Details
posthog-react-native/expoconfig plugin wires the upload into the Xcode bundle phase and the Android Gradle release task, added only whenPOSTHOG_CLI_API_KEYis present, so plain localexpo run:ios/ prebuild stays untouched.expo export --dump-sourcemap+posthog-cli hermes upload, wired into the deploy workflow viaeas env:exec(replaces a stale TODO claiming this CLI didn't exist).Testing steps