chore: cleanup API dependencies

[Flarna]

Which problem is this PR solving?

Address unresolved comments from #2892.

Short description of the changes

Move api-metrics into dependency instead of mixing dep/peer-dep.
Use fixed version for components part of the lerna project.
Move api-metrics to dev-dependency in exporter prometheus.

Type of change

How Has This Been Tested?

CI, local

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[Flarna]

An alternative would be to move api-metrics into peer-dep like api at all places.

Please note also that api-metrics has api as a dependency. Therefore having api-metrics as a dependency one has automatically api as dependency (not as peer-dependency like if metrics is not used).

[codecov]

Codecov Report

Merging #2904 (0846ce1) into main (75cbf5d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2904   +/-   ##
=======================================
  Coverage   93.73%   93.73%           
=======================================
  Files         187      187           
  Lines        6145     6145           
  Branches     1308     1308           
=======================================
  Hits         5760     5760           
  Misses        385      385           

Impacted Files	Coverage Δ
...ry-exporter-prometheus/src/PrometheusSerializer.ts	95.12% <ø> (ø)

[dyladan]

Does this also need to be added to peer dependencies?

[dyladan]

Used in src/PrometheusSerializer.ts line 27

[dyladan]

Or real dependencies

[Flarna]

It imports only a type import type { MetricAttributes } from '@opentelemetry/api-metrics'; and the place where it is used is not exported. Therefore it's only needed at compile time.

[dyladan]

I think when users depend on the exporter the typescript libcheck will still look for api-metrics even just for types won't it? The API will definitely be there because it would be useless to have the exporter without it, but I think it is not strictly a dev dependency when it is type only. I think this is the same thing that happened in contrib when the packages being instrumented have their types imported.

[Flarna]

The lib check will only complain if it is part of an exported API or inside a file which is part of the exported API.

But the serialize function is internal and therefore not even included in PrometheusSerializer.d.ts. Maybe you remember open-telemetry/opentelemetry-js-contrib#932 where I solved a similar problem by moving the internal types into an internal file.

But as metrics-api will be present anyway because of other deps it's maybe better to move it back. This protects us also from accidentally run into a libcheck problem in future just by using a type somewhere else.

[dyladan]

Sounds good thanks for the explanation