fix(otlp-transformer): move api-logs to dependencies

[pichlermarc]

Which problem is this PR solving?

@opentelemetry/otlp-transformer declares a peer dependency on @opentelemetry/api-logs that causes the other signal-specific exporters not to work without it. So, we need to include it as a regular dependency, as we did with metrics.

Fixes #3794

Short description of the changes

• Removes peer dependency, adds a regular dependency.
• disables peer-api-check for @opentelemetry/api-logs

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Existing tests

[codecov]

Codecov Report

Merging #3798 (efd00b8) into main (8fc7689) will not change coverage.
The diff coverage is n/a.

❗ Current head efd00b8 differs from pull request most recent head 42ab9cb. Consider uploading reports for the commit 42ab9cb to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3798   +/-   ##
=======================================
  Coverage   93.20%   93.20%           
=======================================
  Files         298      298           
  Lines        9057     9057           
  Branches     1864     1864           
=======================================
  Hits         8442     8442           
  Misses        615      615           

[llc1123]

Maybe we should split otlp-transformer into 3 packages? This package has dependencies of SDKs of all 3 signals, which is not common in most projects.

[Flarna]

Maybe we should split otlp-transformer into 3 packages? This package has dependencies of SDKs of all 3 signals, which is not common in most projects.

I wonder why otlp transformer has a runtime dependency to SDKs at all. I would assume it needs at max a few types but no real functionality.

But I think this PR focuses on fixing the linked issue so doing a rework in that area is likely out of scope here.

[llc1123]

Maybe we should split otlp-transformer into 3 packages? This package has dependencies of SDKs of all 3 signals, which is not common in most projects.

I wonder why otlp transformer has a runtime dependency to SDKs at all. I would assume it needs at max a few types but no real functionality.

But I think this PR focuses on fixing the linked issue so doing a rework in that area is likely out of scope here.

This is because:

• If an imported type appears in the declaration file, it should be listed in dependencies for type checks.
• enums are not just types. They have js codes after tsc compilation.

[Flarna]

• If an imported type appears in the declaration file, it should be listed in dependencies for type checks.

This can (and in my opinion should) be avoided by keeping the relevant mapping code internal. Only the public API surface is relevant in that regard.

Yes, enums are bad in that regard. They could be extracted into a smaller, shared package if needed.

In principle it should be possible to replace the OTel SDK here by a self made SDK (but reuse API). Reusing OTel export pipleline cant be done in that case. But I doubt it's a major issue and I don't think it's a required setup by spec.

[llc1123]

This can (and in my opinion should) be avoided by keeping the relevant mapping code internal. Only the public API surface is relevant in that regard.

The package mainly exports functions that do the transformation, which has parameter of the type imported from the SDK. One idea is that we make a separate package (maybe called specification?) that only exports types and enums and is shared between SDKs and other packages.

[pichlermarc]

But I think this PR focuses on fixing the linked issue so doing a rework in that area is likely out of scope here.

I agree, we need to address this in the future. Right now, this fixes the problem with 0.39.0.
I created an issue to follow up on this, we can move the discussion there: #3799

Edit: formatting

[SimenB]

Thanks for the quick turnaround!