Description
Problem Statement
With the recent v8 release (but also in the past with previous majors) we changed a couple of properties on the global globalThis.__SENTRY__
carrier object. For example, the APIs on .hub
and .acs
changed, causing issues like #12155, #12054 or (indirectly) #12179.
Solution Brainstorm
Our idea to work around most of these problems is to create version properties on the __SENTRY__
object:
globalThis.__SENTRY__ = {
version: '8.3.0', // <-- this can be used by e.g. spotlight or the loader script to access the "correct" key
'8.3.0': { // <-- SDK adds this along with `version` when first populating the carrier object
acs: {...}
stack: {...}
}
acs: {...} // <-- older SDKs can still put their version of acs, hub, etc. onto the carrier object
hub: {...}
}
caveat: There's still potential for race conditions who gets to write version
. I'm not sure what heuristic we choose here but we have this problem today as well, just on a broader level. Some ideas:
- The first one to populate
.version
wins. Maybe this is good enough, it's definitely the easiest and most bundle-size efficient heuristic - Newest SDK wins. More bundle size (semver comparison); no-one guarantees that the "main" SDK is in fact the one with the highest version
- Add init option or API to mark SDK as main SDK. If set, it can override
.version
if it's already populated. Can of course be abused π
Additionally, we can also use this to log a warning if we detect multiple props that suggest 2+ initialized SDKs.