Skip to content

ref(server-utils): Move ServerRuntimeClient and node stack parser out of core - #23833

Draft
mydea wants to merge 1 commit into
fn/move-server-only-apis-to-server-utilsfrom
fn/move-server-runtime-client-to-server-utils
Draft

ref(server-utils): Move ServerRuntimeClient and node stack parser out of core#23833
mydea wants to merge 1 commit into
fn/move-server-only-apis-to-server-utilsfrom
fn/move-server-runtime-client-to-server-utils

Conversation

@mydea

@mydea mydea commented Sep 1, 2026

Copy link
Copy Markdown
Member

Note

Stacked on #23826 (base branch = fn/move-server-only-apis-to-server-utils). The node-stack-trace move depends on anr already being out of core, which happens in #23826. Merge #23826 first; the base will retarget to develop after.

Moves the base ServerRuntimeClient (+ ServerRuntimeClientOptions / ServerRuntimeOptions) and the node stack-trace parser (nodeStackLineParser, node, filenameIsInApp) out of @sentry/core/server into @sentry/server-utils, and adds @sentry/server-utils as a dependency to @sentry/node-native and @sentry/bundler-plugins.

Exposing core internals (the reason these couldn't move before): unlike the earlier moves, these two import a handful of non-public core internals. Rather than grow the public @sentry/core API, they're re-exported from the semi-internal @sentry/core/server entrypoint (mostly _INTERNAL_-prefixed, matching the existing convention there) for server-utils to consume:

  • normalizeStackTracePath (for the stack parser)
  • DEFAULT_TRANSPORT_BUFFER_SIZE, addUserAgentToTransportHeaders, _getTraceInfoFromScope, span-streaming INTEGRATION_NAME (for ServerRuntimeClient)

Decisions:

  • ServerRuntimeOptions was extracted from the shared types/options.ts (which stays in core for ClientOptions et al.) into its own server-utils types file.
  • @sentry/node-native and @sentry/bundler-plugins were the only two consumers without a server-utils dependency; they now have one. Every other runtime SDK already depended on server-utils and keeps re-exporting these symbols under the same names, so there is no user-facing change.
  • The moved ServerRuntimeClient test's metric cases were reworked to drive the processMetric client hook directly rather than reading the internal metric buffer — so no metric internals were exposed (the metric-buffer accessor stays private to core's own metrics tests).

… of core

Moves the base `ServerRuntimeClient` (with `ServerRuntimeClientOptions` /
`ServerRuntimeOptions`) and the node stack-trace parser (`nodeStackLineParser`,
`node`, `filenameIsInApp`) out of `@sentry/core/server` into
`@sentry/server-utils`.

Unlike the earlier moves, these two touch a handful of core internals that are
not part of core's public API. Rather than expand the public `@sentry/core`
surface, those internals are re-exported (mostly `_INTERNAL_`-prefixed, matching
the existing convention) from the semi-internal `@sentry/core/server` entrypoint
for `@sentry/server-utils` to consume: `normalizeStackTracePath`,
`DEFAULT_TRANSPORT_BUFFER_SIZE`, `addUserAgentToTransportHeaders`,
`_getTraceInfoFromScope`, and the span-streaming integration name.

`ServerRuntimeOptions` was extracted out of the shared `types/options.ts` (which
must stay in core for `ClientOptions` etc.) into its own server-utils types file.

`@sentry/server-utils` is added as a dependency to `@sentry/node-native` and
`@sentry/bundler-plugins`, the only two consumers that did not already depend on
it, so they can import `filenameIsInApp` / `nodeStackLineParser` /
`ServerRuntimeClient` from there. Every other runtime SDK already depends on
server-utils and keeps re-exporting these under the same names, so there is no
user-facing change.

The moved `ServerRuntimeClient` test's metric-enrichment cases were reworked to
drive the `processMetric` client hook directly instead of reaching into the
internal metric buffer, so no metric internals had to be exposed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant