@sentry/nextjs 10.72.0+: importing the server entry under vitest happy-dom throws "The URL must be of scheme file" (vendored bundler plugin import.meta shim reads `document`)

[kurtschmidt]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

10.73.0 (also 10.72.0). 10.71.0 and earlier are fine.

Framework Version

Next 16.3.4, React 19.2.8, vitest 5.0.0, happy-dom 20.14.0, Node 26.8.1 (also reproduced on the Node 24 GitHub Actions runner)

Link to Sentry event

No response

Reproduction Example/SDK Setup

Minimal, no Sentry config at all. Three files:

package.json

{ "name": "sentry-happydom-repro", "private": true, "type": "module",
  "devDependencies": { "vitest": "5.0.0", "happy-dom": "20.14.0" },
  "dependencies": { "@sentry/nextjs": "10.73.0", "next": "16.3.4", "react": "19.2.8", "react-dom": "19.2.8" } }

vitest.config.ts

import { defineConfig } from 'vitest/config'
export default defineConfig({ test: { environment: 'happy-dom' } })

repro.test.ts

import { test, expect } from 'vitest'
import * as Sentry from '@sentry/nextjs'
test('importing @sentry/nextjs under happy-dom', () => {
  expect(typeof Sentry.captureException).toBe('function')
})

Steps to Reproduce

1. pnpm install
2. pnpm vitest run → fails at import time (below).
3. pnpm vitest run --environment node → passes.
4. pnpm add @sentry/nextjs@10.71.0 && pnpm vitest run → passes.

In our real app (Next 16, ~570 vitest suites, environment: 'happy-dom' as the project default because it also has component tests) the 10.72.0/10.73.0 bump made 54 suites fail at import, i.e. every server-side module that imports @sentry/nextjs.

Expected Result

import * as Sentry from '@sentry/nextjs' loads under a DOM-like test environment the way it did through 10.71.0. Reading @sentry/nextjs in a test file should not require the bundler plugin to resolve its own loader path, and certainly not via document.

Actual Result

 FAIL  repro.test.ts [ repro.test.ts ]
TypeError: The URL must be of scheme file
 ❯ fileURLToPath node_modules/.pnpm/@sentry+server-utils@10.73.0/node_modules/node_modules/@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.mjs:5:35
 ❯ Module.<anonymous> node_modules/.pnpm/@sentry+server-utils@10.73.0/node_modules/@sentry/server-utils/build/cjs/orchestrion/bundler/webpack.js:5:17

Additional Context

Root cause, as far as I can tell: @sentry/server-utils/build/cjs/vendored/@apm-js-collab/code-transformer-bundler-plugins/dist/esm/webpack.js (new vendored code in 10.72.0) carries the classic rollup import.meta.url CommonJS shim:

var _documentCurrentScript = typeof document !== 'undefined' ? document.currentScript : null;
var LOADER_PATH = require$$0.resolve(require$$0.dirname(url.fileURLToPath(
  (typeof document === 'undefined'
    ? require('u' + 'rl').pathToFileURL(__filename).href
    : (_documentCurrentScript && _documentCurrentScript.tagName.toUpperCase() === 'SCRIPT' && _documentCurrentScript.src
       || new URL('vendored/@apm-js-collab/.../webpack.js', document.baseURI).href)))), ...

The module is server-only and is loaded by Node's CJS loader via @sentry/nextjs's server entry, but under happy-dom (or jsdom) document is defined on the worker global, so the shim takes the browser branch, builds an http://localhost/... URL from document.baseURI, and fileURLToPath throws. The LOADER_PATH computation runs at module top level, so the throw happens on import, before any Sentry API is touched.

Either evaluating LOADER_PATH lazily (only when the webpack plugin is actually constructed) or using __filename directly in the CJS build (it is never a browser artifact) would fix it. We are holding at 10.71.0 with a Dependabot ignore for >= 10.72.0, < 10.74.0 until then.

[linear-code]

JS-3634

[chargome]

Hey thanks for reporting, the fix already landed but is not yet released, will make sure this happens this week!