chore: update core dependencies stable ^1.3.1 experimental ^0.29.2

[blumamir]

BEGIN_COMMIT_OVERRIDE
feat: update core dependencies stable ^1.3.1 experimental ^0.29.2
END_COMMIT_OVERRIDE

Which problem is this PR solving?

Update dependencies and dev dependencies to use stable ^1.3.1 and experimental ^0.29.2.
The caret is added to dev dependencies since it already pulls the latest version via transitive dependencies on other core packages. If the version is pinned, we end up with multiple core package versions which might not always be compatible. This fix should guarantee that we use the same version everywhere, which was the cause for CI failure in the past few releases.

Since this is a delicate subject, I would appreciate a thorough review and be sure that everyone interested is comfortable with this change.

Short description of the changes

[Flarna]

Why should we pin an old version?
Such pinning caused a lot problems in previous releases that new SDK was unusable with instrumentations from contrib.

And if pinning is the way to go - why not @opentelemetry/instrumentation?

[blumamir]

Why should we pin an old version?

That is not an old version, but the version that the entire monorepo is aligned to currently in master.
The CI fails because we mix versions 1.2.0 and 1.3.0 since some of them are pinned in instrumentation dev dep, and others are introduced via transitive dependency on the caret range (like in the fix mentioned above).
I think we should thrive to have the same version everywhere when building and testing contrib.

Such pinning caused a lot problems in previous releases that new SDK was unusable with instrumentations from contrib.

I only changed the test-utils package which is a dev dependency, so to my understanding, it should not affect any usage for users which consume the released packages.

And if pinning is the way to go - why not @opentelemetry/instrumentation

Since instrumentations depend on it with caret, so I wanted to be align to make sure we pull the same version everywhere

[blumamir]

Apparently, that did not fix the issue yet.
The contrib monorepo still mixes version 1.2.0 and 1.3.0 via caret vs pinned dependencies:

• all node instrumentations pin @opentelemetry/sdk-trace-base to 1.2.0 which makes sense to me.
• web instrumentations depends on caret range ("@opentelemetry/sdk-trace-base": "^1.0.0", "@opentelemetry/sdk-trace-web": "^1.0.0") which pulls in 1.3.0.

I am not sure what should be the right fix here 🤷‍♂️

@Flarna do you have any suggestions?

[Flarna]

What about using caret versions for @opentelemetry also for dev dependencies?

Another option would be to stop trying to be compatible across versions and pin again everything and release everything once a new SDK was made. But as far as I remember the target was to avoid this.

[blumamir]

@Flarna - can you understand why the build is not happy:

Error: test/compatibility.test.ts(44,7): error TS2345: Argument of type 'SimpleSpanProcessor' is not assignable to parameter of type 'SpanProcessor'.
  Types of property 'onStart' are incompatible.
    Type '(_span: Span, _parentContext: Context) => void' is not assignable to type '(span: Span, parentContext: Context) => void'.
      Types of parameters '_span' and 'span' are incompatible.
        Type 'import("/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@opentelemetry/sdk-trace-web/node_modules/@opentelemetry/sdk-trace-base/build/src/Span").Span' is not assignable to type 'import("/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@opentelemetry/sdk-trace-base/build/src/Span").Span'.
          Types have separate declarations of a private property '_spanContext'.
Error: test/longTask.test.ts(67,7): error TS2345: Argument of type 'SimpleSpanProcessor' is not assignable to parameter of type 'SpanProcessor'.Error: test/compatibility.test.ts(44,7): error TS2345: Argument of type 'SimpleSpanProcessor' is not assignable to parameter of type 'SpanProcessor'.
  Types of property 'onStart' are incompatible.
    Type '(_span: Span, _parentContext: Context) => void' is not assignable to type '(span: Span, parentContext: Context) => void'.
      Types of parameters '_span' and 'span' are incompatible.
        Type 'import("/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@opentelemetry/sdk-trace-web/node_modules/@opentelemetry/sdk-trace-base/build/src/Span").Span' is not assignable to type 'import("/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@opentelemetry/sdk-trace-base/build/src/Span").Span'.
          Types have separate declarations of a private property '_spanContext'.
Error: test/longTask.test.ts(67,7): error TS2345: Argument of type 'SimpleSpanProcessor' is not assignable to parameter of type 'SpanProcessor'.

I remember it was fixed by @dyladan after releasing 1.2.0

[Flarna]

ok, got catched by a similar issue by myself now but not bound to @opentelemetry/contrib-test-utils.

Latest contrib and latest core packages are not compatible because caret ranges for GA packages allow minor updates but only patch for experimental.

As a result contrib instrumentations pick @opentelemetry/[email protected] but also @opentelemetry/[email protected] which results in problems and inconsistency.

[Flarna]

I think we have to update all packages here to depend on ^0.29.0 and additionally use 1.3.0 or ^1.0.0 in dev-dependencies.

We should be aware that a semver minor change in experimental (0.x.y range) is similar for NPM as a semver major in GA ranges.

[blumamir]

I think we have to update all packages here to depend on ^0.29.0 and additionally use 1.3.0 or ^1.0.0 in dev-dependencies.

That makes sense. But still what I am missing is why ts complains about "Types have separate declarations of a private property '_spanContext'." I remember dan refactored the code to use only interfaces and not concrete types.

[Flarna]

I remember it was fixed by @dyladan after releasing 1.2.0

As far as I know typescript doesn't allow to mix classes from two instances of the same module (even if they have the same version). Only interfaces can match but SimpleSpanProcessor is a class.

Most likely the reason is that an instanceof check would fail as it compares the constructor instance which exists twice if package is not deduped.

[Flarna]

I remember dan refactored the code to use only interfaces and not concrete types.

I think only ReadableSpan was changes but can't remember in detail. It would be needed to refactor the complete SDK and remove all classes from public interface to really fix this.

[blumamir]

Updated the PR to use 1.3.0 and 0.29.0. Hope that will not cause any new issues

[blumamir]

Now @opentelemetry/host-metrics fails to build with many errors such as:

src/metric.ts:173:7 - error TS2554: Expected 1-2 arguments, but got 3.

I guess there were some changes in the metrics apis which need to be applied, but I am not very familiar with the metrics 😕

[codecov]

Codecov Report

Merging #1042 (84a97a9) into main (3e2f9c5) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1042   +/-   ##
=======================================
  Coverage   95.91%   95.91%           
=======================================
  Files          13       13           
  Lines         856      856           
  Branches      178      178           
=======================================
  Hits          821      821           
  Misses         35       35           

[blumamir]

I updated all versions and fixed the built.

node tests are green, but browser tests fails because:

ERROR in ./node_modules/@opentelemetry/resources/build/esm/detectors/HostDetector.js 54:0-36
Module not found: Error: Can't resolve 'os' in '/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/plugins/web/opentelemetry-instrumentation-document-load/node_modules/@opentelemetry/resources/build/esm/detectors'

I have little experience with browser workflows. Any ideas on how to resolve this?

[rauno56]

With the release of open-telemetry/opentelemetry-js#3013 this should now be fine?

[Flarna]

With the release of open-telemetry/opentelemetry-js#3013 this should now be fine?

Don't think so because the actual fix in open-telemetry/opentelemetry-js#3004 changed @opentelemetry/resource but the stable components were not released yet.

[blumamir]

CI is finally green ✅