feat(deno): Stop inlining types from core

[mydea]

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import * as _sentry_core from '@sentry/core';
import { BaseTransportOptions, Options, TracePropagationTargets, ClientOptions, ServerRuntimeClient, Integration, Client } from '@sentry/core';
export { ... } from '@sentry/core';

// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

[lforst]

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

[timfish]

I'll be back at my desk in about an hour and I'll take a proper look

[timfish]

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

[mydea]

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍