ref(core): Export browser-specific span start APIs - #23361
Conversation
size-limit report 📦
|
e69bc0e to
c75bc8e
Compare
c75bc8e to
dc5ae72
Compare
| * | ||
| * See {@link startInactiveSpan} in `@sentry/core` for details. | ||
| */ | ||
| export function startInactiveSpan(options: StartSpanOptions): Span { |
There was a problem hiding this comment.
q: Did you check that our browser SDKs all use this method and not import from core directly? e.g. svelte still does import { debug, startInactiveSpan } from '@sentry/core';
There was a problem hiding this comment.
I'll merge the two first PR in sync to avoid any temporary issues
`@sentry/core/browser` now exports `startSpan`, `startInactiveSpan`, `startSpanManual` and `startIdleSpan` variants that install `spanStreamingIntegration` on the client before starting the span. `@sentry/core` and `@sentry/core/server` keep serving the plain ones. This is what lets `@sentry/browser`'s `init()` stop referencing the integration in a follow-up, so error-only bundles can tree-shake the whole span streaming graph. `init()` still pushes it here, so nothing changes behaviourally or size-wise yet. Because both variants share their names, the root entry's star exports of `server-exports` and `browser-exports` become ambiguous; `index.ts` pins them to the plain variants with explicit re-exports. The same applies to every meta-framework `index.types.ts` that star-exports both its client and server entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dc5ae72 to
47848cf
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 47848cf. Configure here.
| spanIsTracerProviderSpan, | ||
| } from './utils'; | ||
| export { startIdleSpan, TRACING_DEFAULTS } from './idleSpan'; | ||
| export { TRACING_DEFAULTS } from './idleSpan'; |
There was a problem hiding this comment.
Browser span APIs remain ambiguous exports
High Severity
@sentry/core/browser star-exports both the plain startSpan / startInactiveSpan / startSpanManual from the tracing barrel (via shared-exports) and the new browser wrappers, but never disambiguates them. startIdleSpan and spanStreamingIntegration were pulled out of the shared barrel so they do not collide; these three were not. Native ESM treats that as an ambiguous export, CJS __exportStar typically keeps the first (plain) binding, and tsc reports TS2308. The Vitest namespace check can still pass under last-wins bundling, so the browser entry may not actually ship the wrappers this PR is meant to expose.
Reviewed by Cursor Bugbot for commit 47848cf. Configure here.


This PR is a preparation for making
spanStreamingIntegrationtree-shakeable. End state: BrowserSentry.init/client setup no longer referencesspanStreamingIntegrationin code. Instead, everystart*Span*call checks if the integration is already set up. If not, it initializes it. This way, only usage of a span starting API will add the bundle size for spanStreamingIntegration.Before we make the tree shaking-relevant changes to our browser instrumentation, this PR lays the groundwork:
startSpan,startInactiveSpan,startSpanManualandstartIdleSpanto the@sentry/core/browsersubpath exportspanStreamingIntegrationinto@sentry/core/browserstartSpanet. al. are imported from@sentry/coreor any meta framework packages (in user code)