Skip to content

Create versioned global sentry carrier object #12188

Description

@Lms24

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions