Widen dependency ranges for related packages for instrumentation

[mydea]

trafficstars

Related to https://github.com/open-telemetry/opentelemetry-js/issues/4815

I noticed that e.g. @opentelemetry/instrumentation-http or @opentelemetry/instrumentation-fetch all hard-depend on specific versions of e.g. @opentelemetry/instrumentation, core, semantic-conventions etc. Is this really desired?

Based on https://github.com/open-telemetry/opentelemetry-specification/blob/a03382ada8afa9415266a84dafac0510ec8c160f/specification/upgrading.md?plain=1#L97-L122, if I understand correctly, instrumentation should continue to work for following minor releases of core packages. By relaxing e.g. @opentelemetry/core dependencies to e.g. ^1.26.0 etc. we could make compatibility much easier. As of now, it can be pretty hard to update instrumentation.

FWIW all the instrumentation from opentelemetry-js-contrib seems to already do it that way.

If that seems OK (cc @pichlermarc who explained these concepts to me previously) and I am not misunderstanding something, I'd be happy to open a PR updating the version ranges accordingly.

TLDR: I would propose to change e.g. these dependencies in @opentelemetry/instrumentation-http:

"dependencies": {
    "@opentelemetry/core": "1.26.0",
    "@opentelemetry/instrumentation": "0.53.0",
    "@opentelemetry/semantic-conventions": "1.27.0",
    "semver": "^7.5.2"
  },

to

"dependencies": {
    "@opentelemetry/core": "^1.26.0",
    "@opentelemetry/instrumentation": "^0.53.0",
    "@opentelemetry/semantic-conventions": "^1.27.0",
    "semver": "^7.5.2"
  },

and do the same for all instrumentation packages in this monorepo.

[github-actions[bot]]

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.

[mydea]

This is still relevant I believe, I can also just open a PR for this.

[github-actions[bot]]

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.

[oxc]

Seems still relevant, as mentioned here:

We'll eventually unpin it - but [...]

Originally posted by @pichlermarc in https://github.com/open-telemetry/opentelemetry-js/issues/5165#issuecomment-2521245840

Is there a better place to track it?

[oxc]

This adds ~50 MB of duplicated versions of @opentelemetry/semantic-conventions to my AWS lambda layer, unnecessarily eating up a big chunk of the 200 MB limit. Would be nice to find a way to reduce that.

[github-actions[bot]]

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.

[oxc]

Not stale

[pichlermarc]

@oxc @opentelemetry/semantic-conventions was the largest chunk, and we unpinned it already. If you use the latest version of each package you should be able to de-dupe it just fine. Let us know if there's a package that still has it pinned.

[oxc]

Sorry, I was afraid I should have checked in my project first 😄 I checked a few package.jsons and they still seemed to pin exact dependency versions, but I will try on my actual project and report back.

[pichlermarc]

@oxc did you see any improvement with the unpin of @opentelemetry/semantic-conventions? After bumping to SDK 2.0 and dropping a bunch of things in the process we are now in a significantly better state maintainability-wise and that would allow for unpinning @opentelemetry/core as well.

Anyone from @open-telemetry/javascript-maintainers or @open-telemetry/javascript-triagers may initiate this change if they know they can dedicate enough time to issue triage and addressing problems if they arise. This is similar to how we went about unpinning @opentelemetry/semantic-conventions (https://github.com/open-telemetry/opentelemetry-js/pull/5439).