Repository navigation
feat(sentry): Export withSentryConfig from @sentry/junior/nitro - #2340
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Sentry Evalsjunior-behavioral
Base commit junior-integration
Base commit |
dcramer
approved these changes
Oct 29, 2026
Member
|
this needs rebased junior |
Junior apps imported withSentryConfig from @sentry/nitro and pinned that package themselves. The Sentry SDK keeps one client for each SDK version, so an @sentry/nitro version that differs from Junior's @sentry/node finds no client. Its error hook and request spans then do nothing. @sentry/junior now depends on @sentry/nitro through the same catalog as @sentry/node and re-exports withSentryConfig from its nitro entry. The example app, the init scaffold, and the existing-app docs import it from there. The package README no longer tells apps to install @sentry/node. Co-Authored-By: Francesco Gringl-Novy <francesco.novy@sentry.io>
@sentry/nitro names the build release after the commit SHA. initSentry() reports <junior version>+<sha>. withSentryConfig now defaults release.name to the same value, so the uploaded source maps and runtime events use one release. An explicit release.name still wins.
sentry-junior
Bot
force-pushed
the
feat/junior-owns-sentry-nitro
branch
from
October 29, 2026 14:35
74c502f to
64b6c58
Compare
1 task
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Junior apps no longer install
@sentry/nitrothemselves.@sentry/juniornow depends on it, and@sentry/junior/nitroexportswithSentryConfig.The Sentry SDK keeps one client for each SDK version (
globalThis.__SENTRY__[SDK_VERSION]).initSentry()creates that client with Junior's@sentry/node. If an app pins an@sentry/nitroversion that differs from Junior's@sentry/node, the Nitro runtime hooks find no client. The error hook and request spans then do nothing, and nothing reports it. Before this change, each app had to keep its@sentry/nitropin equal to the@sentry/nodeversion inside@sentry/juniorby hand.Now
@sentry/nitroand@sentry/nodeare next to each other in the pnpm catalog, so they get bumped together. Apps write:withSentryConfigis a thin wrapper around the SDK function. It sets one default: the build release name isgetDeploymentServiceVersion(), which is<junior version>+<VERCEL_GIT_COMMIT_SHA>. This is the same release thatinitSentry()reports. Without this default,@sentry/nitronames the build release after the bare commit SHA, so source maps and runtime events would be under two different releases. An explicitrelease.namestill wins. The wrapper types come from@sentry/nitro's own signature, sodist/nitro.d.tsdoes not inline Nitro's types.The
apps/exampleapp, thejunior initscaffold, and theexisting-appdocs use the new import. The package README no longer tells apps to install@sentry/node. That instruction is howgetsentry/junior-prodgot an unused second copy (@sentry/node@10.49.0next to Junior's 10.65.0).Why now:
junior-prodnever adoptedwithSentryConfig, so production source maps are never uploaded. Production stack frames point at_libs/@sentry/junior+[...].mjsaround line 226k withjs_no_source. getsentry/junior-prod#568 is the draft follow-up that uses this export.Trade-off: every Junior app now installs
@sentry/nitro,@sentry/bundler-plugin-core, and@sentry/cli.@sentry/junioralready hard-depends on@sentry/node, so this seemed acceptable. Without a Sentry auth token, the build logs a warning and skips the upload.Not done here: wrapping the Sentry setup inside
juniorNitro()itself.@sentry/nitrodoes not export the module factory for that, and it must change the config before modules run. Doing it here would mean copying SDK internals.Verification
pnpm --filter @sentry/junior build:dist/nitro.jsimports@sentry/nitroas an external dependency, anddist/nitro.d.tsstays small (47 lines).pnpm typecheckandpnpm lintinpackages/junior, andpnpm typecheckinapps/example.vitest runoninit-cli,check-cli, andnitro-plugin-modulepassed.@sentry/nitrochecked the release default. It passed0.264.0+deadbeefwhenVERCEL_GIT_COMMIT_SHAwas set, kept an explicit name, and left the name undefined when no SHA was set.nitro buildinapps/example: one@sentry/core(10.65.0) is in the output, andscripts/check-vercel-output.mjspasses.pnpm build:ciinjunior-prodlinked to this branch: the build passes with one@sentry/core(10.65.0). The upload step ransentry-cli releases new 0.264.0+deadbeef. The sandbox token was not authorized, so the step got a 401 and created no release.pnpm release:checkpasses.via Francesco Gringl-Novy.
--
View Junior Session [Sentry]