Add app install, foreground and background event and application entity tracking

[Matus Tomlein (matus-tomlein)]

Adds 3 internal plugins to the RN tracker:

1. app install tracking that automatically tracks the install event on first run of app
2. app lifecycle tracking that automatically tracks foreground and background events when the app state changes
3. application context entity with info about the app version and build number.

[bundlemon]

BundleMon

Files added (6)

Status	Path	Size	Limits
✅	trackers/javascript-tracker/dist/sp.js	+24.54KB	30KB / +10%
✅	libraries/browser-tracker-core/dist/index.mod ule.js	+23.59KB	25KB / +10%
✅	libraries/tracker-core/dist/index.module.js	+19.5KB	20KB / +10%
✅	trackers/browser-tracker/dist/index.umd.min.j s	+17.44KB	20KB / +10%
✅	trackers/javascript-tracker/dist/sp.lite.js	+17.39KB	20KB / +10%
✅	trackers/browser-tracker/dist/index.module.js	+3.49KB	5KB / +10%

Total files change +105.95KB 0%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history

[Greg Leonard (greg-el)]

nit: Using fallback values for the values we are testing feels a bit off. Maybe something like expect(payloads[0]?.co).toBeUndefined(); could be better? co should never be populated here, so that would catch a case where there is somehow (cosmic ray, act of god, who knows) a value for co that doesn't match one of those schemas.

Or, if we want to still explicitly check for those schemas, the checks could be split like so?:

if (payloads[0]?.co) {
  expect(payloads[0]?.co).not.toContain(MOBILE_APPLICATION_CONTEXT_SCHEMA);
  expect(payloads[0]?.co).not.toContain(APPLICATION_CONTEXT_SCHEMA);
} else {
  expect(payloads[0]?.co).toBeUndefined();
}

[Matus Tomlein (matus-tomlein)]

Sorry, I'm not totally following. The snippet that you shared is doing the same thing as the code above? The only difference I can see is in handling the empty string value – your snippet will raise an error in that case. But I don't think that's something we should be testing at this point, an empty string in the co field would be a problem at a different level (in the tracker core).

co should never be populated here

I didn't want to make this assumption. We might extend the tracker in the future to add more autotracked context entities and I didn't want the test to break in case we do so. Maybe that's not very likely especially since I'm using the tracker core, not the RN tracker here, but I have had to rework unit tests so many times when an unrelated change happens that I'm wary to test more than what the test case actually is supposed to test.

[Miranda Wilson (mscwilson)]

lgtm