Add runtime checks to ensure Sentry dependencies have matching versions

[timfish]

Problem Statement

When users upgrade Sentry, it's key that all the Sentry dependencies get updated to the same version otherwise weird hard-to-debug things happen.

This could be checked at runtime.

Solution Brainstorm

Currently, SDK_VERSION exists only in @sentry/core.

We could add a checkVersion(version: String) function to core that is called from the packages further up the dependency tree and throws if the versions don't match. The packages further up the dependency tree would need their own SDK_VERSION to call this function with.

This wouldn't check any versions "below" core in the dependency tree although I doubt this will be an issue since users rarely depend on anything below core directly.

[lforst]

We could also add a postinstall script in the package.jsons that checks for this

Edit: After thinking about this a bit, it's probably not the best of ideas to have a postinstall script. Some ppl don't like em, some have them disabled, and blocking npm i or yarn add is a bit iffy

[lforst]

Another idea: We could send meta-information on this to Sentry so we can display some warnings directly in the interface.

[timfish]

Still not sure what is the best approach. Runtime and meta-info both have the minor downside of slightly more code in the bundle although I doubt it will be that significant. postinstall could be tricky and I don't know how common it is to exclude running install scripts.

For the JavaScript SDKs outside of this repository, we'd probably want to ensure all the core dependencies match the pinned version too.

[HazAT]

Crazy idea: What if we ship complete packages - with that I mean when we package @sentry/browser we bundle all of our internal services into it - impossible to have diverging versions ever.

[HazAT]

link: #5886

[timfish]

That would work but I guess we'd need to split @sentry/tracing into browser/node first. When you bundle the dependencies, users can no longer install more than one Sentry package.

We'd also need to re-export more things from core/types/utils at the top level so customers can access everything. Or maybe the dependencies could be exported as named exports: @sentry/browser/types

[mydea]

I'll close this, because this is way less of a problem since v8, where almost everything is now re-exported anyhow!