Node 26 - DeprecationWarning: module.register() is deprecated.

[luc122c]

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/nuxt

SDK Version

10.52.0

Framework Version

4.4.5

Link to Sentry event

No response

Reproduction Example/SDK Setup

https://github.com/luc122c/minimal-nuxt-with-sentry

Steps to Reproduce

1. Ensure you are running Node 26 (current)
2. Install the project dependencies: npm install
3. Run the Dev server with tracing: node --trace-deprecation node_modules/nuxt/bin/nuxt.mjs dev

Expected Result

No deprecation notice

Actual Result

 node -v
v26.0.0

 node --trace-deprecation node_modules/nuxt/bin/nuxt.mjs dev
│                                                                   7:38:10 PM
●  Nuxt 4.4.5 (with Nitro 2.13.4, Vite 7.3.3 and Vue 3.5.34)
                                                                    7:38:10 PM
  ➜ Local:    http://localhost:3000/
  ➜ Network:  use --host to expose

  ➜ DevTools: press Shift + Option + D in the browser (v3.2.4)      7:38:10 PM

✔ Vite client built in 15ms                                        7:38:11 PM
✔ Vite server built in 14ms                                        7:38:11 PM
✔ Nuxt Nitro server built in 305ms                           nitro 7:38:11 PM
ℹ Vite server warmed up in 0ms                                     7:38:11 PM
ℹ Vite client warmed up in 1ms                                     7:38:11 PM
[7:38:11 PM]  ERROR  (node:35605) [DEP0205] DeprecationWarning: module.register() is deprecated. Use module.registerHooks() instead.
    at node:internal/util:129:11
    at Module.register (node:internal/modules/esm/loader:969:3)
    at initializeEsmLoader (file:///Users/luc122c/Dev/sentry-deprecation-warning/node_modules/@sentry/node-core/build/esm/sdk/esmLoader.js:23:20)
    at _init (file:///Users/luc122c/Dev/sentry-deprecation-warning/node_modules/@sentry/node-core/build/esm/sdk/index.js:91:5)
    at init (file:///Users/luc122c/Dev/sentry-deprecation-warning/node_modules/@sentry/node-core/build/esm/sdk/index.js:59:10)
    at _init (file:///Users/luc122c/Dev/sentry-deprecation-warning/node_modules/@sentry/node/build/esm/sdk/index.js:48:18)
    at init (file:///Users/luc122c/Dev/sentry-deprecation-warning/node_modules/@sentry/node/build/esm/sdk/index.js:36:10)
    at init (file:///Users/luc122c/Dev/sentry-deprecation-warning/.nuxt/dev/sentry.server.config.mjs:69:18)
    at file:///Users/luc122c/Dev/sentry-deprecation-warning/.nuxt/dev/sentry.server.config.mjs:165:1
    at ModuleJob.run (node:internal/modules/esm/module_job:437:25)

Additional Context

Since the trace points to @sentry/node-core/build/esm/sdk/esmLoader.js:23:20 it is likely this is in other packages, not just Nuxt.

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear-code]

JS-2438

[luc122c]

I asked OpenCode for a summary of the issue including key files and docs, hopefully this is helpful:

Summary

Node 26.0.0 emits a runtime deprecation warning (DEP0205) when module.register() is called, directing users to use module.registerHooks() instead. The Sentry SDK triggers this warning during initialization in @sentry/node-core.

Stack Trace

[DEP0205] DeprecationWarning: module.register() is deprecated. Use module.registerHooks() instead.
  at Module.register (node:internal/modules/esm/loader:969:3)
  at initializeEsmLoader (packages/node-core/build/esm/sdk/esmLoader.js:23:20)
  at _init (packages/node-core/build/esm/sdk/index.js:91:5)
  at init (packages/node-core/build/esm/sdk/index.js:59:10)

Source of the Call

packages/node-core/src/sdk/esmLoader.ts:22-26

const { addHookMessagePort } = createAddHookMessageChannel();
// @ts-expect-error register is available in these versions
moduleModule.register('import-in-the-middle/hook.mjs', import.meta.url, {
  data: { addHookMessagePort, include: [] },
  transferList: [addHookMessagePort],
});

This registers the import-in-the-middle ESM loader hook, which enables automatic instrumentation of ESM-loaded modules. It is called during SDK init at packages/node-core/src/sdk/index.ts:113-115, gated by the registerEsmLoaderHooks option (defaults to true).

Node.js API Reference

• module.register(specifier[, parentURL][, options]) — Added in v20.6.0/v18.19.0, deprecated in v25.9.0, runtime deprecation (DEP0205) in v26.0.0. It registers async customization hooks from an external module, running them on a separate loader thread.

  • Docs: https://nodejs.org/docs/latest/api/module.html#moduleregisterspecifier-parenturl-options

• module.registerHooks(options) — Added in v23.5.0/v22.15.0, Stability 1.2 (Release Candidate). It registers synchronous hook functions (resolve, load) directly inline, running them in-thread without inter-process communication overhead.

  • Docs: https://nodejs.org/docs/latest/api/module.html#moduleregisterhooksoptions

Why This Can't Simply Use module.registerHooks()

The import-in-the-middle/hook.mjs module exports asynchronous hooks:

packages/node-core/node_modules/import-in-the-middle/hook.mjs (v3.0.1):

const { initialize, load, resolve } = createHook(import.meta)
export { initialize, load, resolve }

These hooks call await parentResolve() and await parentLoad() internally (see create-hook.mjs in the IITM package), making them inherently async. module.registerHooks() expects synchronous hook functions — the two APIs are fundamentally incompatible at the hook level. The async hooks (resolve, load) and sync hooks (resolve, load) have the same signatures but different calling conventions.

Existing DEP0205 Handling

packages/node-core/src/integrations/console.ts:47 already filters [DEP0205] from console breadcrumbs:

filter: [
  ...(options.filter || []),
  '[DEP0205] DeprecationWarning',
],

This prevents the deprecation warning from creating breadcrumb noise but does not suppress the warning itself (which goes through process.emitWarning, not console.log).

Version Gating

packages/node-core/src/utils/detection.ts — supportsEsmLoaderHooks() already gates the module.register() call:

if (NODE_MAJOR >= 21 || (NODE_MAJOR === 20 && NODE_MINOR >= 6) || (NODE_MAJOR === 18 && NODE_MINOR >= 19)) {
  return true;
}

This passes on Node 26 (since NODE_MAJOR >= 21), so the module.register() call runs unconditionally on Node 26.

import-in-the-middle Status

• Current version: 3.0.1 (identical to 3.0.0 in content)
• Does not support module.registerHooks() in any published version
• Latest version check shows no update beyond 3.0.1 as of this writing

Affected Packages

The module.register() call is in @sentry/node-core, which means all packages that depend on it are affected: @sentry/node, @sentry/nuxt, and any other platform/ framework SDK that initializes the Node SDK in ESM mode.

Nuxt-Specific Note

packages/nuxt/src/vite/addServerConfig.ts has workarounds that explicitly bundle import-in-the-middle/hook.mjs as a static import to work around bundler limitations with module.register(). This code references module.register() in comments but does not call it directly.

Relevant Files Summary

File	Role
packages/node-core/src/sdk/esmLoader.ts	Calls moduleModule.register() — the source of the deprecation
packages/node-core/src/sdk/index.ts	Calls initializeEsmLoader() during init
packages/node-core/src/utils/detection.ts	Version-gates the ESM loader registration
packages/node-core/src/nodeVersion.ts	Provides NODE_MAJOR, NODE_MINOR, NODE_VERSION
packages/node-core/src/integrations/console.ts	Already filters DEP0205 from breadcrumbs
packages/node-core/src/types.ts	registerEsmLoaderHooks option type
packages/nuxt/src/vite/addServerConfig.ts	Nuxt bundler workaround for IITM hook module

[luc122c]

Related: nodejs/import-in-the-middle#249

[logaretm]

Thanks for the investigation and linking the relevant issue. This is expected at the moment until we migrate off IITM and RITM which are the source of these warnings or until those libs use the new API.

I will ping the relevant people to see if we can address it in the meanwhile.