ref(nextjs)!: Move withSentryConfig to @sentry/nextjs/config - #23628
Merged
Conversation
Member
Author
|
bugbot run |
chargome
force-pushed
the
feat/nextjs-config-subexport
branch
from
August 26, 2026 09:27
3b7c41d to
6c1ba7f
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 3b7c41d. Configure here.
Contributor
size-limit report 📦
|
chargome
force-pushed
the
feat/nextjs-config-subexport
branch
from
August 26, 2026 11:52
6c1ba7f to
42429a0
Compare
Separate build-time config from the SDK runtime by giving `withSentryConfig` and `SentryBuildOptions` their own entry point, matching the other framework SDKs, which expose their build plugins on `./vite`, `./module` and `./middleware` rather than the main entry. `./config` resolves to CommonJS under both conditions, since `next.config.mjs` is loaded by a plain Node ESM loader and the build-time code resolves webpack loader and template paths with `__dirname`, which is not defined in an ES module. This is safe because the module holds no SDK state. Drop the no-op `withSentryConfig` passthroughs from the client and edge builds: they only existed so the name stayed resolvable when Next compiled a module that imported it for those runtimes, which cannot happen now. Add the `.js` extension to the `next/constants` import so the ESM server build is loadable under a plain Node loader, and guard that with a test — Node does no extension resolution for ESM. This is a prerequisite for splitting the `node` export condition into `import`/`require` (#22791), which is left for a follow-up: serving the ESM server build to Next turns two latent problems into build failures, since turbopack can then statically analyse it. Browser-only names that client components import are genuinely absent from the server build, and `cacheComponents` prerendering rejects the `crypto.randomUUID()` inside `captureException`. Both are masked today by CommonJS being opaque. BREAKING CHANGE: `withSentryConfig` and `SentryBuildOptions` are no longer exported from `@sentry/nextjs`. Import them from `@sentry/nextjs/config`. Refs #22791 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
chargome
force-pushed
the
feat/nextjs-config-subexport
branch
from
August 26, 2026 12:11
42429a0 to
2499913
Compare
chargome
marked this pull request as ready for review
August 26, 2026 12:24
chargome
requested review from
andreiborza,
nicohrubec and
s1gr1d
and removed request for
a team
August 26, 2026 12:24
nicohrubec
approved these changes
Aug 26, 2026
| // the name doesn't match an SDK dependency) | ||
| packageSpecificConfig: { | ||
| external: ['next/router', 'next/constants', 'next/headers', 'stacktrace-parser'], | ||
| external: ['next/router', 'next/constants.js', 'next/headers', 'stacktrace-parser'], |
Member
There was a problem hiding this comment.
q: why do we need the ending now?
Member
Author
There was a problem hiding this comment.
This basically belongs to the part where we split the node exports into require and import (which I took out of this pr). There's no export map from nextjs and the esm import broke here, just left it as a safer default
Member
Author
There was a problem hiding this comment.
But currently this does not do anything on webpack/turbopack
| /** | ||
| * Just a passthrough in case this is imported from the client. | ||
| */ | ||
| export function withSentryConfig<T>(exportedUserNextConfig: T): T { |
Member
There was a problem hiding this comment.
q: why do we no longer need the shims here?
Member
Author
There was a problem hiding this comment.
Because it's not exported anymore from the runtime subpath
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
2 participants
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.
Moves
withSentryConfigandSentryBuildOptionsto a new@sentry/nextjs/configentry point, separating build-time code from the SDK runtime. This matches the other framework SDKs, which expose their build plugins on./vite,./moduleand./middlewarerather than the main entry../configresolves to CommonJS under both conditions, sincenext.config.mjsis loaded by a plain Node ESM loader and the build-time code resolves webpack loader and template paths with__dirname, which is not defined in an ES module. Safe because the module holds no SDK state.Breaks every existing
next.config, but at the first build. Runtime APIs untouched. Docs and the wizard need the same change.This is a prerequisite for splitting the
nodeexport condition (#22791), left for a follow-up. Serving the ESM server build to Next breaks two things CommonJS currently hides: 87 browser-only names are missing from the server build, andcacheComponentsprerendering rejects thecrypto.randomUUID()insidecaptureException.Refs #22791