Uh oh!
There was an error while loading. Please reload this page.
ref(nextjs)!: Move withSentryConfig to @sentry/nextjs/config - #23628
Merged
Conversation
chargome
commented
Aug 26, 2026
MemberAuthor
bugbot run |
chargomeforce-pushed
the
feat/nextjs-config-subexport
branch
from
August 26, 2026 09:27
3b7c41d to
6c1ba7fCompareThere 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 📦
|
chargomeforce-pushed
the
feat/nextjs-config-subexport
branch
from
August 26, 2026 11:52
6c1ba7f to
42429a0CompareSeparate 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>
chargomeforce-pushed
the
feat/nextjs-config-subexport
branch
from
August 26, 2026 12:11
42429a0 to
2499913Comparechargome
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 teamAugust 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?
MemberAuthor
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
MemberAuthor
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?
MemberAuthor
There was a problem hiding this comment.
Because it's not exported anymore from the runtime subpath
Uh oh!
There was an error while loading. Please reload this page.
chargome added a commit
that referenced
this pull request
Aug 31, 2026
Exposes `@sentry/nextjs/config` on v10 (additively) and warns once when
`withSentryConfig` is still imported from `@sentry/nextjs`, so users can
make the change on their current major and upgrade to v11 without
touching their config.
```js
// next.config.mjs
- import { withSentryConfig } from '@sentry/nextjs';
+ import { withSentryConfig } from '@sentry/nextjs/config';
```
- No build changes needed — `src/config/index.ts` was already a rollup
entrypoint, only the export map was missing. Resolves to CJS under every
condition, matching v11.
- The main entry routes through a shim so `@sentry/nextjs/config` stays
silent; `preserveModules` keeps both paths on one implementation.
- Runtime warning rather than JSDoc alone, because most `next.config.js`
files are plain JS with no TS server attached.
- `@deprecated` sits on the export site in `index.types.ts` — that's
what the `types` condition resolves to, and tagging the shim made
`no-deprecated` fire on our own re-export.
- `nextjs-16-trailing-slash` moves to a `.mjs` config on the new path —
the only format Next loads through Node's own ESM loader. The other apps
stay on the old import so the back-compat path keeps CI coverage.
Refs #23628
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 freeto 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