Conversation
size-limit report 📦
|
1d990e7 to
9b6ce01
Compare
9b6ce01 to
ae31677
Compare
Moves the guarded startSpan/startInactiveSpan/startSpanManual wrappers and the ensureBrowserSpanStreaming gate from @sentry/core/browser into @sentry/browser-utils, and decouples startIdleSpan from span streaming. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ae31677 to
951561d
Compare
| // The pageload/navigation idle span is started through the unguarded `startIdleSpan`, so - unlike | ||
| // the guarded `startSpan` APIs - nothing installs span streaming for it. We ensure it here. | ||
| // `addIntegration` is idempotent by name, so this is safe even if a span already installed it. | ||
| if (hasSpanStreamingEnabled(client)) { |
There was a problem hiding this comment.
l: Can't we export _INTERNAL_ensureBrowserSpanStreaming from @sentry/browser-utils and use it here instead?
|
|
||
| // Interaction spans are started through `startIdleSpan`, which - unlike the guarded `startSpan` | ||
| // APIs - does not install span streaming itself, so we ensure it here. | ||
| ensureBrowserSpanStreaming(client); |
There was a problem hiding this comment.
q: This means we would need this for every integration that uses startIdleSpan from @sentry/core/browser, is there any safeguard that would prevent missing ensureBrowserSpanStreaming in such integrations? Or maybe a startIdleSpan from @sentry/browser-utils we can use internally that mirrors what startSpan does?
| browserPerformanceTimeOrigin, | ||
| } from '@sentry/core'; | ||
| import { _INTERNAL_ensureBrowserSpanStreaming, startIdleSpan, startInactiveSpan } from '@sentry/core/browser'; | ||
| import { startIdleSpan } from '@sentry/core/browser'; |
There was a problem hiding this comment.
l: Do you think it would be confusing to import certain APIs from borwser-utils and the rest from core/browser?
I noticed startIdleSpan is the only API that is not present in the spanApis in the browser utils, any reason for that?
Stacked on top of #23762 — review/merge that first.
Follow-up to the core entrypoint split: the guarded browser span-start APIs do not belong in
@sentry/core. They exist purely so thatspanStreamingIntegrationis reachable only from code that starts a span, which is a browser-SDK concern, so this moves them down into@sentry/browser-utils(which already sits below@sentry/browserand the framework SDKs).What moves out of
@sentry/core/browser:startSpan/startInactiveSpan/startSpanManual— the guarded wrappers that install span streaming before delegating to the plain core APIs — now live in@sentry/browser-utils. Everything they need is already public on@sentry/core.ensureBrowserSpanStreaming(previously_INTERNAL_ensureBrowserSpanStreaming) moves too, and is now package-private to@sentry/browser-utils. Its only callers are the wrappers andinteractionsIntegration.startIdleSpanstays in@sentry/core/browser, and no longer installs span streaming itself. That responsibility now sits with its callers:interactionsIntegrationensures it insetup(), andbrowserTracingIntegrationcontinues to ensure it inafterAllSetup(guaranteeing the pageload segment streams with browser tracing alone).Decisions
@sentry/core/browseris introduced by ref(core)!: Split browser/server-only exports out of the default entrypoint #23762 and unreleased, and@sentry/browserstill re-exports the wrappers unchanged. The framework SDKs (effect, react-router, svelte, sveltekit) were repointed to packages they already depend on (@sentry/browser/@sentry/svelte), so no new dependencies were added.no-unguarded-span-apissuppression — it is itself the guarded variant the rule steers callers toward.browserTracingIntegrationcan no longer reach the now-private gate, so it installs span streaming inline via core’\s publichasSpanStreamingEnabled+spanStreamingIntegration. This is a small, idempotent duplication of the gate logic; the alternative was keepingensureBrowserSpanStreamingexported, which we chose not to do.XhrBreadcrumbData/XhrBreadcrumbHint/BrowserClientReplayOptionstypes stay in@sentry/core:XhrBreadcrumbHintis referenced by core’\s ownClientsignatures (moving it would invert the dependency), andBrowserClientReplayOptionswas deliberately parked in core to avoid a browser↔replay cycle.