We were still looking for transactions for the root event, but they are normal events now.

…sentry-replay#82)

This moves the core SDK instrumentation handlers into the main plugin class as the typings are more accurate and allows better testing of the handler data transforms as well.

Refactor this handler so that we can re-use `addReplayEvent`. This will help us apply the same logic for our core SDK instrumentation handlers.

…ntry-replay#83)

Previously we did not create replay events after receiving new updates from core SDK (e.g. breadcrumbs) -- they only get flushed after an rrweb event.

This causes breadcrumbs to be attached to a new session instead of the previous session.

e.g. old session -> breadcrumbs -> <idle> (no upload happens)
 --> new session -> rrweb checkout -> upload (with old breadcrumbs)

 Fixes getsentry/sentry-replay#79

Adds an explicit breadcrumb for when a page is unloaded

Add an EventBuffer that compresses events in a webworker.

)

Move typescript and rollup configuration files to `config/`. The root `tsconfig` is required for dev builds and for tooling (e.g. IDEs) to work. It also includes typechecking for tests, which are ignored in production builds.

This would provide a better interface for the session. This fixes/simplifies updating the session directly where previously it would not save to storage, only the session "instance" (object).

This is useful/needed for M1 arch.

…ntry/sentry-replay#96)

…ION` (getsentry/sentry-replay#98)

We are noticing a lot of short sessions that I suspect is related to the visibility change timeout. Keeping the code around and changing the constants in case we decide to tweak this later.

…y#94)

Adds breadcrumbs when user blurs/focuses the page.

![image](https://user-images.githubusercontent.com/79684/176032241-ab0c2664-2beb-4126-8e7e-7022168b2008.png)

…ry-replay#102)

We're going to axe the "visible" breadcrumb, as it is a point of confusion for users (i.e. what is the difference between blur/focus and visibility?) We will be able to get the information we need with focus/blur alone.

)

…y-replay#108)

* Move `@sentry/browser` to devDeps as it is only used in tests.
* Import from `@sentry/core` instead of `@sentry/browser`
* Clean up type imports from `@sentry/hub`

…ay#106)

I suspect we have a lot of "empty" replays due to this issue where we are immediately creating the root replay event. This had the possibility of having a replay w/ no recording events. Unfortunately, after some testing, a lot of short replays still get through because we immediately flush updates after a full DOM checkout. However, this is still needed in order to implement getsentry/sentry-replay#101.

…rong (getsentry/sentry-replay#110)

* `captureReplay` needs to happen before `sendReplay`
* `captureEvent` should only happen after a *successful* `sendReplay`
* fix `sendReplay` promises where it now awaits the retries before resolving

Change the logic for when to flush after a full snapshot checkout. Add
option `initialFlushDelay` to control when to flush.

Do NOT flush on checkout after a session has expired. It will need to
wait for additional user actions before recording the new sessions
replay.