OpenTelemetry JS SDK 3.0.0 and 0.300.0: Drops Node.js 18 and 20

Key facts in the 3.0 release #

• Stable v3.0.0 packages and experimental v0.300.0 packages, with API 1.10.0, announced on 2026-11-05 in Announcing the OpenTelemetry JavaScript SDK 3.0.
• Minimum Node.js raised to >=22.15.0; Node.js 18 and 20 dropped.
• All packages now ship ES Module and CommonJS exports.
• @opentelemetry/api-logs folded into @opentelemetry/api.
• Removed: @opentelemetry/propagator-jaeger, @opentelemetry/exporter-jaeger, @opentelemetry/shim-opentracing and @opentelemetry/shim-opencensus.
• The 2.x versions of stable SDK packages are supported for one year from the 3.0.0 release.

Node.js 18 and 20 Lose Support in SDK 3.x #

The change that affects the most deployments is the runtime floor. The announcement states:

The minimum supported Node.js has been raised to >=22.15.0

Services running on Node.js 18 or 20 must move to 22.15.0 or later before taking the 3.x packages. The project gives its reason: Node.js 20 reached end-of-life in April 2026, and the SIG wants to keep pace with new Node.js majors. Teams that stay on 2.x are covered by the one-year support window described below.

ESM and CommonJS Exports in Every SDK Package #

All packages now ship proper ES Module and CommonJS exports, a change the post says required changes to package entry points. The post expects the result to be "much friendlier to ESM and bundler users." This suggests that projects that load these packages through ESM or a bundler should check their builds on the new entry points after upgrading.

Logs Stabilized: api-logs Merges into the API Package #

With Logs stabilized, all three OpenTelemetry signals are stable in JavaScript, and @opentelemetry/api-logs has been folded into @opentelemetry/api. The API package itself has no breaking changes according to the post. Code that imports the logs API from the separate package will need its import path updated, which this suggests is a required edit for logging code. A separate blog post on Logs stabilization is planned.

Jaeger Exporter, Jaeger Propagator and OpenTracing/OpenCensus Shims Removed #

Several deprecated packages are removed in this major, including the Jaeger exporter and propagator and both shims. Code that still uses @opentelemetry/exporter-jaeger or @opentelemetry/shim-opentracing cannot stay on these packages in 3.x. The post points to its migration guide for the full list of removed packages.

Complex Attributes Reach Span and Log Record APIs #

Support for complex attributes, per OTEP 4485, is added to some parts of the API, specifically span attributes and log record attributes. Resource attributes and metric attributes still accept only simple attributes. Code that sets structured values on resources or metrics should keep to simple types, while span and log record code can use complex values.

Tracing SDK Consolidated into @opentelemetry/sdk-trace #

Multiple Tracing SDK packages are consolidated into @opentelemetry/sdk-trace. The post also says several public types and class names have been renamed or moved, so tracing setup code that imports from the older package layout will need its imports and class references checked against the migration guide.

Auto-Instrumentation Users and the 2.x Support Window #

Users of @opentelemetry/auto-instrumentations-node, as described in the zero-code instrumentation documentation, do not need to change anything. All packages from opentelemetry-js-contrib have also been upgraded to JS SDK 3.x and released. Projects that cannot move yet keep receiving support on 2.x for one year from 3.0.0.

Why the SIG Plans a Major Release Each Year #

The OTel JS SIG has a goal of a new SDK major roughly every year, starting with SDK 2.0 in March 2025. The post links this cadence to keeping pace with new Node.js majors and ecosystem tooling. Removing deprecated and unmaintained packages is given as a reason for 3.0, so the SIG can focus on current features.

Also in this release #

• Packages from opentelemetry-js-contrib released on JS SDK 3.x.
• Public interface renames and moves are listed in the migration guide.

The announcement does not list the individual renamed types or the full set of removed packages, so the migration guide is the place to confirm each import before upgrading.