[v8] Remove `@sentry/hub` package

[AbhiPrasad]

Problem Statement

We have both https://github.com/getsentry/sentry-javascript/tree/master/packages/hub and https://github.com/getsentry/sentry-javascript/tree/master/packages/core, and there should never be a situation where you import @sentry/hub and you aren't using @sentry/core. As such, we should just consolidate this into 1 package (move everything in @sentry/hub into @sentry/core.)

• Less stuff to download from npm
• Less chance of versions getting out of sync
• Easy to understand core -> browser -> react -> nextjs (linear deps)
• Possible bundle size reduction from removing module boundaries

[shezhangzhang]

Why didn't do it in the first place？

[AbhiPrasad]

Maybe @kamilogorek can offer us some history listens on why hub was made a seperate package.

[kamilogorek]

Whole @sentry/minimal was build around @sentry/hub. If you are writing 3rd party integrations, or plug-in widgets, you are not going to depend on @sentry/core, and can use @sentry/hub directly.

[timfish]

Would it be possible to move the hub code without breaking the public API?

We could move the code to core and then have hub only depend on core and re-export the types?

The only reason I suggest this is because it becomes easier to make the changes and iterate on the codebase without creating a load of merge conflicts as v8 approaches. When we get to v8 we'd simply remove the @sentry/hub package?

The only downside I can see is that we'd be exporting the types from two different packages at the same time.

[AbhiPrasad]

We could move the code to core and then have hub only depend on core and re-export the types?

I'm going to go ahead and make the call for us to do this, esp if it makes the work in #5611 easier.

The only downside I can see is that we'd be exporting the types from two different packages at the same time.

Internally, we can shift to only depending on core, so the chances of this causing issues will decrease.

[lobsterkatie]

The only downside I can see is that we'd be exporting the types from two different packages at the same time.

We already do this all over the place, because most wrapper SDKs re-export stuff from the SDKs they wrap. I don't think it's an issue.