What's a sane way for a package to make OTel dependency resolution easier for lots of applications?

[fhwang]

I'm currently helping a large organization with their OpenTelemetry setup, and maintaining a Node package that, for the purposes of this discussion, helps downstream libraries and applications maintain OTel dependencies. It's currently being used in production in 200+ services.

I'm trying to work within a few constraints:

1. NPM is not designed to prevent multiple versions of a given NPM package from being installed within the same application
2. OTel NPM packages are the rare edge case of NPM packages that should not have multiple versions installed in the same application
3. Downstream libraries and applications of this wrapper may want to reference OTel NPM packages themselves

For example, my "wrapper" package depends on a specific version of @opentelemetry/api. I would like an application to be able to reference the exact same version of @opentelemetry/api without having to keep up-to-date in package.json, wrestling with NPM's dependency resolution, etc.

I am considering having the wrapper re-export a bunch of key OTel packages in its own module:

export * as openTelemetryApi from "@opentelemetry/api"

That way, downstream applications can re-import the exact version:

import { openTelemetryApi } from 'wrapper'

const baggage = openTelemetryApi.propagation.createBaggage()

Seems like this would allow applications OTel access, and they can just trust the most recent version of the wrapper offers them something that's internally consistent. Of course, it's a layer of indirection, the wrapper has to actually do the job well, and once in a while there may be surprising changes in the underlying OTel packages. It's also kind of ugly, I suppose.

Does this seem like overkill? Are there easier options I'm missing?