Uh oh!
There was an error while loading. Please reload this page.
fix(v10/nextjs): Fix SDK import crashing under jsdom/happy-dom - #23906
Merged
Conversation
s1gr1d
requested review from
chargome, mydea and nicohrubec
and removed request for
a teamSeptember 2, 2026 08:34
chargome
reviewed
Sep 2, 2026
chargome
left a comment
Member
There was a problem hiding this comment.
q: Keeping this on v10 only bc we split the config and server files in v11 right?
Contributor
size-limit report 📦
|
MemberAuthor
yes, but we should probably port the tests so there's really no regression |
chargome
approved these changes
Sep 2, 2026
Uh oh!
There was an error while loading. Please reload this page.
s1gr1d added a commit
that referenced
this pull request
Sep 2, 2026
…estrion bundler plugins (#23910) Adds one test to the `nextjs-16-cf-workers` e2e app. After the OpenNext build, it scans every script in `.open-next/` (except static assets) and fails if the orchestrion bundler plugins show up, naming the offending files. The plugins are build-time-only, but they used to get compiled into the worker bundle, where an unawaited `WebAssembly.compile()` crashed every cold start. The bundle check is deterministic, unlike waiting for an error to not appear. The below issue is fixed in #23906 already, this PR is just adding the verification. Closes#22794
s1gr1d added a commit
that referenced
this pull request
Sep 3, 2026
…a.url shim (#23935) This is just adding the tests of the v10 PRs to make sure we don't have a regression. Ported tests of two v10 PRs: - #23910 - #23906 One test caught a real problem: the `@sentry/server-utils` CJS build still replaced `import.meta.url` with a snippet that assumes "a `document` global means a browser", crashing under jsdom. ``` "AssertionError: expected [Function] to not throw an error but 'TypeError [ERR_INVALID_URL_SCHEME]: T…' was thrown" ``` The v10 lazy-loading fix needs no porting: on v11, `withSentryConfig` lives in the separate `@sentry/nextjs/config` export, so importing the SDK never reaches the bundler plugins. Fixes#23789
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.
Since 10.72.0, importing
@sentry/nextjson the server crashes when adocumentglobal exists. jsdom and happy-dom define one while tests run in Node (#23789, introduced by #23667).What went wrong:
@sentry/server-utilsnow bundles the code-transformer plugin, compiled from ESM to CJS. Rollup replacesimport.meta.urlwith a snippet that assumes "adocumentglobal means a browser". This is now fixed by always emitting the Node form, since this package only runs in Node.withSentryConfig, so just importing the SDK ran the bundler plugin's module-scope code. The plugins now load lazily when the build config actually runs. Build behavior is unchanged (still synchronous, Next.js webpack configs can't be async), but importing the SDK no longer touches them. This also removes theWebAssembly.compile()call behind the Cloudflare cold-start errors (reference - but needs to be verified #22794)Fixes#23789