Mismatch between 0.27.0 and 0.26.1 libraries

[sstone1]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

I am trying to use @opentelemetry/sdk-node@0.27.0 with @opentelemetry/auto-instrumentations-node@0.26.1 in a TypeScript application.

This fails at build time as those two packages bring in @opentelemetry/api-metrics@0.27.0 and @opentelemetry/api-metrics@0.26.0 respectively.

The following compilation error happens because of the different versions of the same library:

src/opentelemetry.ts:38:3 - error TS2322: Type 'Instrumentation[]' is not assignable to type 'InstrumentationOption[]'.
  Type 'Instrumentation' is not assignable to type 'InstrumentationOption'.
    Type 'import("~/node_modules/@opentelemetry/instrumentation/build/src/types").Instrumentation' is not assignable to type 'import("~/node_modules/@opentelemetry/sdk-node/node_modules/@opentelemetry/instrumentation/build/src/types").Instrumentation'.
      Types of property 'setMeterProvider' are incompatible.
        Type '(meterProvider: import("~/node_modules/@opentelemetry/api-metrics/build/src/types/MeterProvider").MeterProvider) => void' is not assignable to type '(meterProvider: import("~/node_modules/@opentelemetry/sdk-node/node_modules/@opentelemetry/api-metrics/build/src/types/MeterProvider").MeterProvider) => void'.
          Types of parameters 'meterProvider' and 'meterProvider' are incompatible.
            Type 'import("~/node_modules/@opentelemetry/sdk-node/node_modules/@opentelemetry/api-metrics/build/src/types/MeterProvider").MeterProvider' is not assignable to type 'import("~/node_modules/@opentelemetry/api-metrics/build/src/types/MeterProvider").MeterProvider'.
              The types returned by 'getMeter(...)' are incompatible between these types.
                Type 'Meter' is missing the following properties from type 'Meter': createValueRecorder, createValueObserver, createSumObserver, createUpDownSumObserver, createBatchObserver

Will there be a 0.27.0 compatible release of the packages in this repository?

[joekrill]

I'm seeing a similar issue when trying to follow the Koa example (https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/examples/koa). @opentelemetry/instrumentation-koa is v0.27.0, but it has a dependency on @opentelemetry/instrumentation v0.26.0, which doesn't seem right? Especially since there is a @opentelemetry/instrumentation v0.27.0. Meanwhile the @opentelemetry/api is at version 1.03 and @opentelemetry/sdk-trace-base is at v1.0.1.

I have to admit this is my first attempt at using OpenTelemetry, but I'm a bit worried if I move forward with using OpenTelemetry that keeping things up to date is going to be plagued with versioning problems. Is there some sort of recommendation/documentation around which versions I should be using to ensure I'm not going to have conflicts like this?

[tcarrio]

This is an issue I encountered, wiring up an Nest.js app today with the following packages:

"@opentelemetry/auto-instrumentations-node": "^0.26.2",
"@opentelemetry/sdk-node": "^0.27.0",

Seems to be the same issue of properties mismatch with the Instrumentation types

[jpettit]

👍 Simplifying this process would be neat.

And for the consideration of expediency; 0.27.0 has the following fix for web workers: open-telemetry/opentelemetry-js#2465

[sstone1]

@dyladan are you able to comment on this issue please?

[tcarrio]

Looking into the @opentelemetry/auto-instrumentations-node package manifest, it appears to have a dependency on version ^0.26.0 but @opentelemetry/sdk-node appears to be using 0.27.0, which explains the type mismatch.

Seems the scenario @joekrill ran into: the ^0.26.0 version rule won't allow it to install 0.27.0 according to the caret rules in the Node.js docs.

^: It will only do updates that do not change the leftmost non-zero number.

[tcarrio]

I opened a PR to update the @opentelemetry/auto-instrumentations-node package dependencies, which should resolve this issue.

[tcarrio]

Looks like there's a PR that will fix this and more coming in from @dyladan. That provides a more global, atomic update to packages- I'll be closing mine in favor of his 👍

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.