@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789

Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js

Description

@Srbino
Srbino
opened on Aug 31, 2026

Is there an existing issue for this?

  • I have checked for existing issues
  • I have reviewed the documentation
  • I am using the latest SDK release

Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.

How do you use Sentry?

Sentry SaaS (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

10.72.0 and 10.73.0 (10.71.0 is fine)

Framework Version

Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.

Link to Sentry event

N/A — this is a module-load crash, nothing reaches Sentry.

Reproduction Example/SDK Setup

Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.

No test runner or bundler is needed to see it:

mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK

Steps to Reproduce

  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.

Expected Result

The module loads. 10.71.0 does, under an identical setup.

Actual Result

TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:

varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");

The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.

Two things make this worse than it might look:

  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.

Suggested fix

Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.

Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.

Workaround

Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BugNext.jsNode.js

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789
Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js
Description
@Srbino
Srbino
opened on Aug 31, 2026
Is there an existing issue for this?
  •  I have checked for existing issues
  •  I have reviewed the documentation
  •  I am using the latest SDK release
Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.
How do you use Sentry?
Sentry SaaS (sentry.io)
Which SDK are you using?
@sentry/nextjs
SDK Version
10.72.0 and 10.73.0 (10.71.0 is fine)
Framework Version
Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.
Link to Sentry event
N/A — this is a module-load crash, nothing reaches Sentry.
Reproduction Example/SDK Setup
Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.
No test runner or bundler is needed to see it:
mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK
Steps to Reproduce
  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.
Expected Result
The module loads. 10.71.0 does, under an identical setup.
Actual Result
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:
varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");
The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.
Two things make this worse than it might look:
  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.
Suggested fix
Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.
Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.
Workaround
Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.
Activity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
BugNext.jsNode.js
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789
Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js
Description
@Srbino
Srbino
opened on Aug 31, 2026
Is there an existing issue for this?
  •  I have checked for existing issues
  •  I have reviewed the documentation
  •  I am using the latest SDK release
Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.
How do you use Sentry?
Sentry SaaS (sentry.io)
Which SDK are you using?
@sentry/nextjs
SDK Version
10.72.0 and 10.73.0 (10.71.0 is fine)
Framework Version
Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.
Link to Sentry event
N/A — this is a module-load crash, nothing reaches Sentry.
Reproduction Example/SDK Setup
Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.
No test runner or bundler is needed to see it:
mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK
Steps to Reproduce
  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.
Expected Result
The module loads. 10.71.0 does, under an identical setup.
Actual Result
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:
varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");
The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.
Two things make this worse than it might look:
  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.
Suggested fix
Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.
Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.
Workaround
Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.
Activity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
BugNext.jsNode.js
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789
Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js
Description
@Srbino
Srbino
opened on Aug 31, 2026
Is there an existing issue for this?
  •  I have checked for existing issues
  •  I have reviewed the documentation
  •  I am using the latest SDK release
Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.
How do you use Sentry?
Sentry SaaS (sentry.io)
Which SDK are you using?
@sentry/nextjs
SDK Version
10.72.0 and 10.73.0 (10.71.0 is fine)
Framework Version
Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.
Link to Sentry event
N/A — this is a module-load crash, nothing reaches Sentry.
Reproduction Example/SDK Setup
Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.
No test runner or bundler is needed to see it:
mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK
Steps to Reproduce
  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.
Expected Result
The module loads. 10.71.0 does, under an identical setup.
Actual Result
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:
varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");
The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.
Two things make this worse than it might look:
  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.
Suggested fix
Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.
Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.
Workaround
Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.
Activity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
BugNext.jsNode.js
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789
Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js
Description
@Srbino
Srbino
opened on Aug 31, 2026
Is there an existing issue for this?
  •  I have checked for existing issues
  •  I have reviewed the documentation
  •  I am using the latest SDK release
Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.
How do you use Sentry?
Sentry SaaS (sentry.io)
Which SDK are you using?
@sentry/nextjs
SDK Version
10.72.0 and 10.73.0 (10.71.0 is fine)
Framework Version
Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.
Link to Sentry event
N/A — this is a module-load crash, nothing reaches Sentry.
Reproduction Example/SDK Setup
Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.
No test runner or bundler is needed to see it:
mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK
Steps to Reproduce
  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.
Expected Result
The module loads. 10.71.0 does, under an identical setup.
Actual Result
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:
varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");
The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.
Two things make this worse than it might look:
  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.
Suggested fix
Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.
Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.
Workaround
Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.
Activity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
BugNext.jsNode.js
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789
Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js
Description
@Srbino
Srbino
opened on Aug 31, 2026
Is there an existing issue for this?
  •  I have checked for existing issues
  •  I have reviewed the documentation
  •  I am using the latest SDK release
Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.
How do you use Sentry?
Sentry SaaS (sentry.io)
Which SDK are you using?
@sentry/nextjs
SDK Version
10.72.0 and 10.73.0 (10.71.0 is fine)
Framework Version
Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.
Link to Sentry event
N/A — this is a module-load crash, nothing reaches Sentry.
Reproduction Example/SDK Setup
Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.
No test runner or bundler is needed to see it:
mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK
Steps to Reproduce
  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.
Expected Result
The module loads. 10.71.0 does, under an identical setup.
Actual Result
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:
varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");
The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.
Two things make this worse than it might look:
  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.
Suggested fix
Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.
Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.
Workaround
Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.
Activity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
BugNext.jsNode.js
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789
Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js
Description
@Srbino
Srbino
opened on Aug 31, 2026
Is there an existing issue for this?
  •  I have checked for existing issues
  •  I have reviewed the documentation
  •  I am using the latest SDK release
Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.
How do you use Sentry?
Sentry SaaS (sentry.io)
Which SDK are you using?
@sentry/nextjs
SDK Version
10.72.0 and 10.73.0 (10.71.0 is fine)
Framework Version
Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.
Link to Sentry event
N/A — this is a module-load crash, nothing reaches Sentry.
Reproduction Example/SDK Setup
Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.
No test runner or bundler is needed to see it:
mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK
Steps to Reproduce
  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.
Expected Result
The module loads. 10.71.0 does, under an identical setup.
Actual Result
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:
varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");
The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.
Two things make this worse than it might look:
  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.
Suggested fix
Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.
Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.
Workaround
Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.
Activity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
BugNext.jsNode.js
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom #23789
Closed
#23935
Closed
@sentry/nextjs 10.72.0+ throws "The URL must be of scheme file" at module scope under jsdom/happy-dom#23789
#23935
Assignees
s1gr1d
Labels
BugNext.jsNode.js
Description
@Srbino
Srbino
opened on Aug 31, 2026
Is there an existing issue for this?
  •  I have checked for existing issues
  •  I have reviewed the documentation
  •  I am using the latest SDK release
Searched for fileURLToPath, must be of scheme file, code-transformer-bundler-plugins, and jsdom/happy-dom combinations before filing; nothing matched. #22794 and #23611 look like sibling symptoms of the same structural cause — the server entry eagerly pulling in the orchestrion bundler plugin — but neither covers this crash.
How do you use Sentry?
Sentry SaaS (sentry.io)
Which SDK are you using?
@sentry/nextjs
SDK Version
10.72.0 and 10.73.0 (10.71.0 is fine)
Framework Version
Next.js 16.3.3, Node 24.14.0. Reproduces with no framework at all — see below.
Link to Sentry event
N/A — this is a module-load crash, nothing reaches Sentry.
Reproduction Example/SDK Setup
Importing @sentry/nextjs throws at module scope whenever a document global exists — which is the normal state of affairs under jsdom or happy-dom, i.e. in any Vitest or Jest test using a DOM environment.
No test runner or bundler is needed to see it:
mkdir sentry-repro &&cd sentry-repro && npm init -y
npm i @sentry/nextjs@10.73.0
cat > repro.cjs <<'JS'globalThis.document = { baseURI: 'http://localhost:3000/' }require('@sentry/nextjs')console.log('loaded OK')JS
node repro.cjs # throws
node -e "require('@sentry/nextjs')"# control: prints loaded OK
Steps to Reproduce
  1. Install @sentry/nextjs@10.72.0 or @10.73.0.
  2. Define any document global with a baseURI — or just run a Vitest suite with environment: 'happy-dom' (or Jest with testEnvironment: 'jsdom') that imports the SDK, directly or transitively.
  3. Load the module.
Expected Result
The module loads. 10.71.0 does, under an identical setup.
Actual Result
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at Object.fileURLToPath (node:internal/url:1608:11)
at Module.<anonymous> (node_modules/@sentry/server-utils/build/cjs/vendored/
@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js:9:61)
at Module._compile (node:internal/modules/cjs/loader:1812:14)

The node export condition of @sentry/nextjs reaches @sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js, which pulls in the vendored @apm-js-collab/code-transformer-bundler-plugins. That module computes LOADER_PATH at module scope from a dual browser/Node guard:
varLOADER_PATH=path.resolve(path.dirname(url.fileURLToPath(typeofdocument==='undefined'
? pathToFileURL(__filename).href
: (_documentCurrentScript&& ... ||newURL('vendored/.../webpack.js',document.baseURI).href))),"..","cjs","webpack-loader.cjs");
The guard is typeof document === 'undefined', so it treats "a document exists" as "this is a browser". Under jsdom/happy-dom that is false — the code is running in Node, and __filename is right there and valid. It takes the browser branch, builds http://localhost:3000/vendored/... from document.baseURI, and hands that to fileURLToPath, which only accepts file:.
Two things make this worse than it might look:
  • It throws at module scope, so it is not catchable by the importer and takes down the whole module graph. In our suite, 11 test files stopped loading; every assertion inside them still passed, so the failure did not look like a dependency problem at all.
  • It arrives through lockfile regeneration, not a reviewed bump. Our package.json says ^10.70.0 and never changed; a routine Dependabot PR for unrelated packages re-resolved the tree and moved the SDK from 10.71.0 to 10.72.0 as a side effect.
Suggested fix
Prefer a positive Node check over an absence-of-document check, e.g. gate on typeof __filename !== 'undefined' (or process.versions?.node) first and fall back to the document-based path only when there is genuinely no module path available. The bundler emitting the dual guard is @apm-js-collab/code-transformer-bundler-plugins, so the fix may belong there rather than in this repo — but it ships vendored inside @sentry/server-utils, which is where it reaches users.
Deferring the LOADER_PATH computation until the plugin is actually used would also fix it, and would additionally address the class of problem in #22794 and #23611: a bundler-time plugin should not be doing filesystem path resolution just because someone imported the SDK.
Workaround
Pinning below 10.72.0 ("@sentry/nextjs": "<10.72.0" in pnpm.overrides). Setting resolve.conditions: ['browser'] in Vitest also gets past it, but only by resolving the client build, which then wants next/router — absent in an App Router project — and it changes resolution for every other package too.
Activity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
BugNext.jsNode.js
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions