refactor: switch from dd-trace to dd-trace-electron

[rochdev]

Motivation

Replace the public dd-trace dependency with dd-trace-electron, the tracing build published for
the Electron SDK. The dedicated package keeps the SDK-owned tracer isolated from an application's
own dd-trace installation and removes the OpenFeature, ASM, IAST, and profiling dependencies that
the Electron integration does not use.

Changes

• Replace dd-trace@6.10.0 with dd-trace-electron@6.11.0, the nearest published Electron build on
  the same major line.
• Load, initialize, type, and report the version of dd-trace-electron while preserving the tracing
  configuration, sampling rules, exporter flushing, and telemetry behavior from current main.
• Update the Vite, Webpack, esbuild, and Rollup configurations to externalize and copy
  dd-trace-electron and its runtime dependency tree.
• Update package allowlists and root, playground, and e2e lockfiles.
• Update the README, architecture overview, dependency documentation, changelog, test wording, and
  integration packaging assertions in response to Cursor's review.
• Clarify that dd-trace-electron retains optional OpenTelemetry API packages while omitting the
  unused native product dependencies.
• Rebase onto current main, which preserves integration-app .yarnrc.yml and lockfiles during
  setup. Running integration initialization confirmed it leaves those tracked files unchanged,
  addressing refactor: switch from dd-trace to dd-trace-electron #186 (comment).

This PR was generated by Codex.

Test instructions

Run:

yarn format:check
yarn build
yarn typecheck
yarn test:unit
yarn test:integration:init
yarn test:integration

Validation performed locally:

• 1,054 unit tests passed.
• 77 integration tests passed across Webpack, Vite, esbuild CJS/ESM, and electron-builder's plugin-
  and packager-managed dependency staging modes; 13 project-specific tests were skipped as expected.
• Integration setup left no .yarnrc.yml or lockfile changes.
• Formatting, build, typecheck, and targeted ESLint passed.

Checklist

• Tested locally (playground)
• Added or updated unit tests for this change.
• Added or updated e2e/integration tests for this change.
• Updated related documentation.
• Agentic code review findings addressed or explicitly dismissed.

[cursor]

PR Review — Score: 4.5 / 5

Solid dependency swap with consistent updates across bundler plugins, instrumentation entry points, lockfiles, and integration-app Yarn config. The expanded ARCHITECTURE.md tracing section clearly explains why dd-trace-electron exists and how copyPackageTree behavior changes. I would approve this PR; the remaining gaps are documentation polish and the manual smoke test the author already flagged.

Why 4.5: Mechanical rename is thorough (all three bundler plugins, rollup externals, prelude/instrument, Tracing.ts, unit-test mock, e2e .yarnrc.yml allowlists). The architecture write-up captures the deduplication benefit and the defense-in-depth shift for optional-dependency filtering. npmPreapprovedPackages is the right tool for a freshly published internal package under Renovate's age gate.

Why not 5: Customer-facing README.md still describes dd-trace throughout (setup diagram, bundler section). The Monitoring Architecture diagram at the top of ARCHITECTURE.md was not updated to match the new tracing section. No CHANGELOG entry yet for a notable runtime dependency change, and the manual smoke test in the PR test plan is still unchecked.

---

Findings

• [Minor] README still references dd-trace — The primary getting-started doc, architecture diagram, and bundler-plugin section all still name dd-trace instead of dd-trace-electron.
• [Minor] ARCHITECTURE overview diagram stale — The Monitoring Architecture mermaid block at the top of docs/ARCHITECTURE.md (and its narrative) still labels the tracer as dd-trace while the tracing section below was updated.
• [Minor] Missing CHANGELOG entry — Swapping the core tracing dependency is customer-visible; worth a note under the next release.
• [Nit] Residual dd-trace mentions — e2e/integration/README.md and instrument-prelude.spec.ts test titles still say dd-trace.

---

Architectural flow

sequenceDiagram
    participant App as Main app
    participant Plugin as Bundler plugin
    participant Inst as instrument entry
    participant DTE as dd-trace-electron
    participant Patches as SDK patches
    participant Chan as diagnostics_channel
    participant SP as SpanProcessor

    App->>Plugin: build main bundle
    Plugin->>Plugin: externalize dd-trace-electron
    Plugin->>Plugin: copyPackageTree minimal deps

    App->>Inst: import instrument first
    Inst->>DTE: require (skips OpenFeature register)
    Inst->>DTE: tracer.init electron exporter
    Inst->>Patches: patch BrowserWindow, ipc, net

    Patches->>DTE: startSpan / inject / extract
    DTE->>Chan: datadog apm electron export
    Chan->>SP: finished spans
    SP->>SP: enrich and convert to RUM resources

Loading

Before: The SDK depended on the public dd-trace package. Its entrypoint ran openfeature/register on load, and its package.json declared large optional native modules. Bundler plugins had to externalize dd-trace and rely on copyPackageTree walking only dependencies to keep ~84 MB of optional modules out of packaged apps.

After: The SDK depends on dd-trace-electron, a purpose-built build with a slimmer entrypoint and no OpenFeature/ASM/IAST/profiling deps in its tree. Bundler plugins externalize and copy dd-trace-electron instead; optional-dependency filtering remains as defense-in-depth. Using a distinct package name also prevents Yarn/npm from deduplicating the SDK tracer with a customer's own direct dd-trace install.

  

_{Sent by Cursor Automation: electron-sdk reviews}

[cdn34dd]

Overall it's a good improvement, left a couple of comments regarding the new library and some questions regarding how future features will be handled.

[cdn34dd]

Running yarn test:integration:init && yarn test:integration on the repo root, seems to leave hanging .yarnrc.yml instead of a clean tree, we should check what's causing it.

[rochdev]

Fixed

[cdn34dd]

When looking at the dependencie each variant of dd-trace has, there is a drastic reduction on the number of dependencies.

npm view dd-trace@5.109.0 dependencies optionalDependencies peerDependencies --json
{
  "dependencies": {
    "dc-polyfill": "^0.1.11",
    "opentracing": ">=0.14.7",
    "import-in-the-middle": "^3.0.1"
  },
  "optionalDependencies": {
    "oxc-parser": "^0.132.0",
    "@datadog/pprof": "5.15.0",
    "@opentelemetry/api": ">=1.0.0 <1.10.0",
    "@datadog/libdatadog": "0.9.4",
    "@datadog/native-appsec": "11.0.1",
    "@datadog/native-metrics": "3.1.2",
    "@opentelemetry/api-logs": "<1.0.0",
    "@datadog/wasm-js-rewriter": "5.0.1",
    "@datadog/openfeature-node-server": "2.0.0",
    "@datadog/native-iast-taint-tracking": "4.2.0"
  }
}

when compared to the new electron variant:

npm view dd-trace-electron@5.118.0 dependencies optionalDependencies peerDependencies --json
{
  "dependencies": {
    "dc-polyfill": "^0.1.11",
    "import-in-the-middle": "^3.3.2",
    "opentracing": ">=0.14.7"
  },
  "optionalDependencies": {
    "@opentelemetry/api": ">=1.0.0 <1.10.0",
    "@opentelemetry/api-logs": "<1.0.0"
  }
}

but is this as lean as this new variant can be, for instance, does it really need to include the optionalDependencies ?

[rochdev]

We're actually moving optional dependencies back to regular dependencies and going with a different strategy later on. They could thus only be removed if you don't need OpenTelemetry support at all for now, unless we vendor OpenTelemetry but I'm not sure if api-logs supports that.

[cdn34dd]

Let's say at some point we need to add more feature to dd-trace-electron, for instance main process profiling, what is the current plan ? Is it to include it in this package or simply create a new package (dd-trace-electron-profiling) ?

[rochdev]

Generally speaking, there are 2 ways to handle this:

1. Single package that contains everything.
2. Multiple packages that are installed individually and then connected together.

For now only 1 would be supported, but we're working on improving our package structure to allow both: individual packages will be available for each product, and the entry point package (for example dd-trace-electron) will stitch everything together, but it would technically also be possible to use the individual packages directly to save even more on package size.

[cdn34dd]

Coming back to the package dependencies, now that the electron-sdk owns the net and IPC instrumentation and dd-trace is used for span creation, context and the electron exporter, could we double-check whether all its regular runtime dependencies are still required?

  "dependencies": {
    "dc-polyfill": "^0.1.11",
    "import-in-the-middle": "^3.3.2",
    "opentracing": ">=0.14.7"
  }

In particular, it would be useful to understand which runtime paths still require each dependency and whether any could be removed from an Electron-specific build.

I'm asking because we’re trying to simplify the bundler plugins and evaluating whether electron-sdk and potentially dd-trace-electron could stop being externalized. Removing these runtime dependencies could make bundling both packages much simpler.

[rochdev]

For dc-polyfill, this is needed for any use of diagnostics channels since we support many versions of Node. A lot of our internals use it, so it has to stay. It's possible we could vendor it though, we would have to look into it.

For import-in-the-middle, it was not written in a way that can be vendored. It's possible we could rewrite it to make that possible, but that might require a major version of the library itself. Worth doing only if it becomes a hard requirement to have no dependencies.

For opentracing, it's an artifact of the past and we could definitely remove it.

[rochdev]

@cdn34dd I think I replied to all your questions and resolved any concerns, PTAL.