[BUG]: esbuild plugin injects absolute import-in-the-middle path, breaks ESM bundles since dns/promises instrumentation (5.105.0+)

[kazaz-lumida]

Tracer Version(s)

5.105.0, 5.106.0, 5.111.0 (reproduced on these, but likely happening on everything else as well)

Node.js Version(s)

26.4.0

Bug Report

When bundling a Node.js ESM application with the dd-trace/esbuild plugin, the build fails on dd-trace 5.105.0 and later. The failure started after dns/promises instrumentation landed (#8404, shipped in 5.105.0).

For ESM builds, the datadog-esbuild plugin wraps instrumented Node builtins (e.g. node:dns/promises) by generating synthetic modules that register hooks via import-in-the-middle. The generated code uses an absolute filesystem path from require.resolve():

import { register } from '/…/node_modules/.pnpm/import-in-the-middle@3.3.0/node_modules/import-in-the-middle/lib/register.js';

esbuild cannot resolve absolute-path import specifiers during bundling, even when the target file exists on disk. The build fails before any runtime code runs.

This is the same class of bug already fixed for the rewriter in #8526 (dc-polyfill absolute paths → bare specifiers / file:// URLs), but the esbuild plugin still uses JSON.stringify(require.resolve('import-in-the-middle/lib/register.js')) in packages/datadog-esbuild/index.js (~line 357).

Expected: dd-trace/esbuild works with ESM output format on 5.105.0+ (same as 5.104.0).

Actual: esbuild fails with Could not resolve "<absolute path>/import-in-the-middle/lib/register.js".

Bisect:

dd-trace	nx run jobs-service:build:production (ESM + dd-trace/esbuild)
5.104.0	✅ Passes
5.105.0+	❌ Fails on node:dns/promises._dd_esbuild_intercepted

Suggested fix: Emit a bare specifier instead of an absolute path, e.g.:

import { register } from 'import-in-the-middle/lib/register.js';

…and document that consumers should list import-in-the-middle (and possibly dc-polyfill) in esbuild external, consistent with the existing @datadog/pprof guidance.

Additional context

• Related merged PR: #8404 feat(dns): instrument dns.promises API — regression trigger in 5.105.0
• Related merged PR: #8526 fix(rewriter): emit valid ESM imports for instrumented modules — same absolute-path pattern fixed for rewriter, not esbuild
• Datadog esbuild docs: https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/nodejs/#bundling-with-esbuild
• Workaround we use locally: a small esbuild plugin that rewrites absolute import-in-the-middle/lib/register.js paths to a bare external specifier (happy to share if useful)
• 5.104.0 (last version that bundles successfully with dd-trace/esbuild)

Reproduction Code

esbuild config (minimal):

'use strict';

const esbuild = require('esbuild');
const ddTracePlugin = require('dd-trace/esbuild');

esbuild
  .build({
    entryPoints: ['src/main.ts'], // any entry that transitively imports node:dns/promises
    bundle: true,
    platform: 'node',
    format: 'esm',
    outfile: 'dist/main.js',
    plugins: [ddTracePlugin],
    external: ['@datadog/pprof', '@datadog/native-metrics']
  })
  .catch(err => {
    console.error(err);
    process.exit(1);
  });

package.json:

{
  "dependencies": {
    "dd-trace": "5.111.0"
  }
}

Install with pnpm (isolated node_modules layout makes the absolute path long, but the bug reproduces with any package manager — esbuild rejects absolute imports regardless).

Trigger: Any bundled dependency graph that pulls in node:dns/promises as an ESM import (common via undici / HTTP clients). On 5.104.0 the dns/promises hook did not exist, so the interception path was never hit.

Error Logs

✘ [ERROR] Could not resolve "/…/node_modules/.pnpm/import-in-the-middle@3.3.0/node_modules/import-in-the-middle/lib/register.js"

    ../../../../_dd_esm_internal_/node:dns/promises._dd_esbuild_intercepted:2:25:
      2 │ import { register } from "/…/node_modules/.pnpm/import-in-the-middle@3.3.0/node_modules/import-in-the-middle/lib/register.js";
        ╵                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

NX   Build failed with 1 error:
../../../../_dd_esm_internal_/node:dns/promises._dd_esbuild_intercepted:2:25: ERROR: Could not resolve "/…/node_modules/.pnpm/import-in-the-middle@3.3.0/node_modules/import-in-the-middle/lib/register.js"

With DD_TRACE_DEBUG=true during build, the datadog-esbuild plugin logs resolution of instrumented modules before the failure.

Tracer Config

Runtime tracer is initialized via dd-trace.init() (no custom config object; env-driven):

import ddTrace from 'dd-trace';

if (process.env.NODE_ENV !== 'development' && process.env.NODE_ENV !== 'test') {
  ddTrace.init();
}

Relevant environment variables (ECS / production):

DD_SERVICE=jobs-service
DD_ENV=staging|production
DD_PROFILING_ENABLED=true
DD_RUNTIME_METRICS_ENABLED=true
DD_LOGS_INJECTION=true

The failure occurs at bundle time, before the tracer runs.

Operating System

Local dev:
Darwin 24.6.0 (macOS).

Production Docker image:
node:26.4.0-trixie-slim (Debian)

Bundling

ESBuild

[BridgeAR]

Thank you for the report, I am looking into this. To properly fix it, we will have to add a new API to import-in-the-middle and with that updated, we can simplify our bundler implementation and have it work for builtins with slashes

[kazaz-lumida]

Thanks @BridgeAR ! Looking forward to it! I see you already opened a PR 🚀
Do you think you can get it in the next release of dd-trace?