Bump OpenTelemetry off the ^0.205.0 line: upstream already dropped protobufjs, and it unblocks js-genai#1883

[ScottMansfield]

Follow-up to #797. This started as "file an upstream issue asking OpenTelemetry to move to protobufjs 8" and turned out to need no upstream work at all — OTel already did it, then removed protobufjs entirely. We're pinned to a range that can't reach either change.

What upstream did

@opentelemetry/otlp-transformer	protobufjs
0.205.0 ← what we resolve to	^7.3.0
0.206.0	^7.3.0
0.210.0	8.0.0
0.215.0	^8.0.1
0.220.0, 0.221.0	none

core/package.json pins the OTLP packages at ^0.205.0. For a 0.x version npm treats ^0.205.0 as >=0.205.0 <0.206.0, so we are held on the one line that still carries protobufjs 7.

Why it matters beyond the bytes

@google/genai and @opentelemetry/otlp-transformer are currently the only two protobufjs consumers in the production tree, and they're the reason js-genai#1883 (bump genai to protobufjs ^8.4.0) is currently a regression for us: with otel on ^7.3.0 and genai on ^8, npm installs both majors side by side.

Bumping OTel removes the conflict and flips that issue from a cost to a win:

scenario	tree	pkgs	protobufjs
today	112.2 MB	171	one copy, v7 (otel + genai)
otel bumped	101.6 MB	204	one copy, v7 (genai only)
otel bumped + js-genai#1883	99.6 MB	193	one copy, v8; all 9 @protobufjs/* helpers gone

So the ordering is: bump OTel first, then js-genai#1883 becomes adoptable and is worth −2.0 MB / −11 packages instead of +3.8 MB.

The catch: package count goes up

This is not a clean win and shouldn't be treated as one.

today:        112.2 MB   171 pkgs
otel bumped:  101.6 MB   204 pkgs     (-10.6 MB, +33 pkgs)

Newer OTel is more finely split, so we trade ~33 packages for ~10.6 MB. Given #626, #784 and #785 have all been optimising package count, that's a direct tension and needs a call on which axis matters more — or whether the OTLP exporters should move behind optional peers anyway (the "OpenTelemetry block" item in #797), which would make the question moot for most consumers.

I haven't evaluated the API delta. Going from 0.205.0 → 0.221.0 and sdk-* 2.1.x → 2.10.x is a real jump and core/src/telemetry/{setup,google_cloud}.ts would need checking, along with the two @google-cloud/opentelemetry-cloud-*-exporter optional peers which have their own OTel range constraints.

Suggested sequence

1. Assess the OTel API delta for core/src/telemetry/* and the two GCP exporter peers.
2. Decide the package-count-vs-bytes tradeoff, ideally alongside the optional-peer question from Tracking: @google/genai block is 30.4 MB reducible on the byte axis (171 → 87 pkgs, 112 → 63 MB with all in-flight work) #797.
3. If we bump: adopt js-genai#1883 once it lands, and drop the ⚠️ warning on it in Tracking: @google/genai block is 30.4 MB reducible on the byte axis (171 → 87 pkgs, 112 → 63 MB with all in-flight work) #797.

Related

• Tracking: @google/genai block is 30.4 MB reducible on the byte axis (171 → 87 pkgs, 112 → 63 MB with all in-flight work) #797 — tracking issue; this resolves one of its future-work items
• js-genai#1883 — blocked on this to be worth adopting
• proto-loader: Update protobufjs dependency to 8.x grpc/grpc-node#3067 — the other protobufjs ^7 holdout, an open PR. Not in our production tree (it arrives via the @google-cloud/opentelemetry-cloud-trace-exporter optional peer and @grpc/grpc-js), so it doesn't gate anything here, but it's the same migration. Added downstream measurements there.

[ScottMansfield]

Re-measured on the new baseline now that #796's migration to @google-cloud/agentplatform@0.11.0 is done (branch fix/migrate-agentplatform). The numbers shift, and the package-count tension I flagged above is confirmed but smaller than first measured.

Clean install of core's production dependencies, empty directory, warm cache, Node v26.7.0, apparent bytes:

config	tree	packages
old baseline (@google-cloud/vertexai)	106.4 MB	171
current (agentplatform, #796)	90.4 MB	163
+ all @opentelemetry/* at latest	78.6 MB	186

So the OTel bump is now worth −11.8 MB but +23 packages on top of the migration (previously measured as −10.6 MB / +33 packages against the older base).

What the bump actually fixes

Three separate duplications collapse, all of which are version skew between the exporters pinned at 2.1.0 and the newer sdk packages:

package	now	after bump
@opentelemetry/core	6 copies	1
@opentelemetry/resources	5 copies	1
@opentelemetry/sdk-trace-base	3 copies	1
protobufjs	1 (v7, shared with genai)	1
node-fetch	2 copies	1

The @opentelemetry/core × 6 is the striking one — the exporter-*-otlp-http packages depend on @opentelemetry/core at an exact 2.1.0, not a range, so every sdk package that resolves 2.10.0 gets its own nested copy.

Don't bump resource-detector-gcp on its own

Worth recording as a trap. @opentelemetry/resource-detector-gcp@^0.40.0 pins gcp-metadata@^6, which drags a whole second HTTP stack:

resource-detector-gcp@0.40 → gcp-metadata@6 → gaxios@6 → node-fetch@2
google-auth-library@10.9   → gcp-metadata@8 → gaxios@7 → node-fetch@3 → fetch-blob → web-streams-polyfill

resource-detector-gcp@0.56.0 moves to gcp-metadata@^8, which looks like it should collapse that. Measured on its own it is a regression:

	tree	packages
current	90.4 MB	163
+ resource-detector-gcp@^0.56.0 only	94.0 MB (+3.6)	199 (+36)

It dedupes node-fetch and google-logging-utils, but pulls in a second generation of @opentelemetry/core/resources that does not dedupe against the 2.1.0-pinned exporters. It only pays off as part of the whole-block bump — worth doing in one change, not incrementally.

Still blocked on upstream

web-streams-polyfill (8.8 MB) survives all of the above. It arrives via google-auth-library → gaxios → node-fetch@3 → fetch-blob, and no version bump available to us removes it — gaxios imports node-fetch unconditionally off-browser. That needs googleapis/google-cloud-node#9101, which is still open.

protobufjs stays on v7 either way: with OTel bumped, @opentelemetry/otlp-transformer no longer needs it at all, leaving @google/genai (^7.5.4) as the sole consumer — so js-genai#1883 becomes adoptable and worth −2.0 MB / −11 packages, as described above.