feat(otlp-transformer)!: add new entrypoints for non-core features #5259
Conversation
chancancode
force-pushed
the
oltp-transformer-entrypoints
branch
from
ea19ceb to
89e13d2
Compare
|
@pichlermarc given the timing, I opted to target the |
|
I also checked js-contrib, it doesn't look like these exports are currently used there. |
chancancode
force-pushed
the
oltp-transformer-entrypoints
branch
from
89e13d2 to
380d557
Compare
In preparation of stabilizing `@opentelemetry/otlp-transformer`, this commit introduces some new entrypoints for the package: * `@opentelemetry/otlp-transformer/protobuf`: utilities for working with the OTLP binary protobuf format * `@opentelemetry/otlp-transformer/json`: utilities for working with the OTLP JSON format * `@opentelemetry/otlp-transformer/experimental`: features to remain in experimental status post-stabilization The intent of separating out the first two entrypoints is to both aid bundlers with tree-shaking, but also to prevent the irrelevant code from running at all, since the generated prtobuf code is known to cause problems in certain environments (e.g. see open-telemetry#4987, open-telemetry#5096). The last of those entrypoints is currently empty, but expected to be utilized in future commits as features are triaged as part of the stabilization effort. Fixes open-telemetry#5216
chancancode
force-pushed
the
oltp-transformer-entrypoints
branch
from
0a88ed1 to
c0d0966
Compare
| "esnext": "build/esnext/index.js", | ||
| "types": "build/src/index.d.ts", | ||
| "main": "build/src/index.js", | ||
| "exports": { |
There was a problem hiding this comment.
Given things are conditionally exported now, do we also want to expose a ./generated export so that projects that want to access the deserialization logic this package uses, they can just use this package for that?
There was a problem hiding this comment.
@SebastienGllmt I am pretty sure @pichlermarc have slightly different plans around the details, so I'd follow #5264 and #5263 instead; leaving this open for now but I'm pretty sure those combined would supersede this one
|
Oh sorry, @chancancode I had assigned myself to #5216 and worked on this at around the same time you did. I had myself assigned as I expected a shift in requirements while I worked out some of the details. I ended up introducing entrypoints for each signal (logs/metrics/trace), and then for each type (json/protobuf). Having it split into more pieces should give us more flexibility. So I'd prefer my PR #5263 over this PR here. (a side note: if you start working on an issue that's already assigned feel free to comment or reach out to the assigned person first, then we can avoid duplicate work. I can only speak for myself, but for issues that I'm assigned to I'm usually more than happy to hand it to someone as long as I have not started work on it yet 🙂) |
|
Sounds good! |
Which problem is this PR solving?
In preparation of stabilizing
@opentelemetry/otlp-transformer, this commit introduces some new entrypoints for the package:@opentelemetry/otlp-transformer/protobuf: utilities for working with the OTLP binary protobuf format@opentelemetry/otlp-transformer/json: utilities for working with the OTLP JSON format@opentelemetry/otlp-transformer/experimental: features to remain in experimental status post-stabilizationThe intent of separating out the first two entrypoints is to both aid bundlers with tree-shaking, but also to prevent the irrelevant code from running at all, since the generated prtobuf code is known to cause problems in certain environments (e.g. see #4987, #5096).
The last of those entrypoints is currently empty, but expected to be utilized in future commits as features are triaged as part of the stabilization effort (#4584).
Fixes #5216
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:
addedupdated