Hoist @sentry/types into @sentry/core

[lforst]

Description

We found that moving @sentry/types into @sentry/core would clean up some architecture, docs, and prevent footguns like diverging package versions.

This task involves:

• Moving the entire content of @sentry/types into @sentry/core and exporting everything that was exported from types also from core (this also means we don't have to depend on @sentry/types in @sentry/core)
• Removing the contents of types and re-exporting all the previously exported exports from @sentry/core
• Removing all references to @sentry/types from docs and replace with @sentry/core
• Deprecating all the exports in @sentry/types

ATTENTION: Because of #9840 which is also planned for v9, we do not want to export the Client type from @sentry/core. The same goes for the Scope type. Instead, we want to export Client as an alias for BaseClient as part of this task, and the Scope interface as we have it in @sentry/types should not make it into @sentry/core.

We don't want to delete @sentry/types in the v9 major, just deprecate. The friction for deletion would likely be too high.

[timfish]

We don't want to delete @sentry/types in the v9 major, just deprecate

I don't understand this statement.

• If we're not going to release a v9 version of @sentry/types why not delete it from the repo?
• If we are going to release a v9 version of @sentry/types what will be in it? Won't it diverge from what gets moved to core?

[lforst]

@timfish this decision was pushed by @mydea. The idea is to limit breakage.

• We will still be publishing the types package in v9. Everything is just deprecated.
• Yes it will diverge. New types won't be added to the types package. If we update types in core they will obv also be updated in the types package. However, existing setups won't break.

The theory is that too many people depend on the types package through docs and similar.

[timfish]

If we update types in core they will obv also be updated in the types package

Oh ok, I was missing this bit of context!