feat(mobile): attach app version to all custom events#2404
Merged
Conversation
Mirrors #2372 on the React Native app: register `app_version` as a PostHog super property at boot so every captured event (including autocapture and manual screen events) carries the shipped app version. The version is resolved from `expo-application.nativeApplicationVersion` with a fallback to `Constants.expoConfig.version` from `app.json`, so OTA-updated binaries still report their real shipped version while Expo Go / web builds continue to fall back to the config value. Generated-By: PostHog Code Task-Id: d2c2384c-852a-4130-a07e-476395746cc1
Contributor
Prompt To Fix All With AIFix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
apps/mobile/src/lib/posthog.test.ts:40-67
**Prefer parameterised tests for `getAppVersion`**
The three `getAppVersion` cases share an identical structure — set `nativeApplicationVersion`, set `expoConfig`, call `getAppVersion`, assert the result. The project convention is to consolidate these into a single `it.each` table rather than repeating the scaffolding three times. The same pattern applies to the two "does nothing" cases in `registerAppVersion`.
Reviews (1): Last reviewed commit: "feat(mobile): attach app version to all ..." | Re-trigger Greptile |
Comment on lines
+40
to
+67
| describe("getAppVersion", () => { | ||
| it("prefers the native application version when present", async () => { | ||
| expoApplication.nativeApplicationVersion = "9.8.7"; | ||
| expoConstants.expoConfig = { version: "0.0.0-test" }; | ||
|
|
||
| const { getAppVersion } = await import("./posthog"); | ||
|
|
||
| expect(getAppVersion()).toBe("9.8.7"); | ||
| }); | ||
|
|
||
| it("falls back to the Expo config version when no native version is available", async () => { | ||
| expoApplication.nativeApplicationVersion = null; | ||
| expoConstants.expoConfig = { version: "1.2.3" }; | ||
|
|
||
| const { getAppVersion } = await import("./posthog"); | ||
|
|
||
| expect(getAppVersion()).toBe("1.2.3"); | ||
| }); | ||
|
|
||
| it("returns null when neither source has a version", async () => { | ||
| expoApplication.nativeApplicationVersion = null; | ||
| expoConstants.expoConfig = null; | ||
|
|
||
| const { getAppVersion } = await import("./posthog"); | ||
|
|
||
| expect(getAppVersion()).toBeNull(); | ||
| }); | ||
| }); |
Contributor
There was a problem hiding this comment.
Prefer parameterised tests for
getAppVersion
The three getAppVersion cases share an identical structure — set nativeApplicationVersion, set expoConfig, call getAppVersion, assert the result. The project convention is to consolidate these into a single it.each table rather than repeating the scaffolding three times. The same pattern applies to the two "does nothing" cases in registerAppVersion.
Context Used: Do not attempt to comment on incorrect alphabetica... (source)
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/mobile/src/lib/posthog.test.ts
Line: 40-67
Comment:
**Prefer parameterised tests for `getAppVersion`**
The three `getAppVersion` cases share an identical structure — set `nativeApplicationVersion`, set `expoConfig`, call `getAppVersion`, assert the result. The project convention is to consolidate these into a single `it.each` table rather than repeating the scaffolding three times. The same pattern applies to the two "does nothing" cases in `registerAppVersion`.
**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
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
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
app_versionas a PostHog super property at boot so every captured event (autocapture + manual screen events) carries the shipped app version, with no per-call wiring required.expo-application.nativeApplicationVersionand falls back toConstants.expoConfig.versionfromapp.json, so OTA-updated binaries report their real shipped version while Expo Go / web builds fall back to the config value.RootLayoutNavnext touseScreenTracking, so it runs insidePostHogProvideronce the client is ready.Test plan
pnpm --filter @posthog/mobile test— 112 tests pass, including the newsrc/lib/posthog.test.ts(7 cases covering version resolution, no-op paths, and super-property registration).app_versionis present in PostHog event properties.