loadModule throws ReferenceError: module is not defined from the ESM build (default parameter is outside the try/catch)

[martin-k-m]

The problem

loadModule throws ReferenceError: module is not defined when called from the ESM build.

build/esm/utils/node.js:9:

function loadModule(moduleName, existingModule = module) {
  let mod;
  try {
    mod = dynamicRequire(existingModule, moduleName);
  } catch {}
  ...

build/esm/package.json declares {"type": "module"}, so Node loads that file as an ES module — where there is no module binding.

The try/catch in the body cannot help. A default parameter is evaluated at call entry, before the body begins, so the ReferenceError is raised outside the guard the author wrote. That is what makes this fail loudly rather than degrade to undefined the way the rest of the function is written to.

loadModule is re-exported from the ESM index (build/esm/index.js:161), so it is reachable as public API.

Reproduce

npm i @sentry/core@10.73.0

probe.mjs:

import { loadModule } from '@sentry/core'
loadModule('node:path')

ReferenceError: module is not defined

I ran a control in the same file first — a bare module reference — to confirm the scope really is an ES module rather than something my harness leaked:

control: ReferenceError
loadModule is: function
THREW: ReferenceError: module is not defined

Verified against @sentry/core@10.73.0, freshly downloaded from npm.

Scope, honestly

Passing existingModule explicitly avoids it, and I suspect most internal callers do. So the blast radius depends on whether anyone calls the one-argument form from ESM — the export makes that legal and the types allow it, which is why I am reporting it rather than assuming nobody does.

The CJS build is fine, which is presumably why this has not surfaced.

Fix

The usual ESM equivalent — createRequire(import.meta.url) — or making the parameter required on the ESM path, or defaulting it to something that exists in both module systems.

Notes

Found by an automated checker I'm building that flags CommonJS bindings in files Node resolves as ES modules. I verified this by hand against the published 10.73.0 tarball and searched open and closed issues for an existing report before filing.

[linear-code]

JS-3596