-
Notifications
You must be signed in to change notification settings - Fork 838
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(otlp-exporter-base): use dynamic import instead of require in esm/esnext build #5220
base: main
Are you sure you want to change the base?
fix(otlp-exporter-base): use dynamic import instead of require in esm/esnext build #5220
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5220 +/- ##
==========================================
- Coverage 94.60% 94.59% -0.02%
==========================================
Files 315 315
Lines 8011 8011
Branches 1617 1617
==========================================
- Hits 7579 7578 -1
- Misses 432 433 +1
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my experience importing a core module before hooking doesn't actually cause any issues and it gets instrumented fine, we use fs
before anything else to load a config file and it's never been a problem.
Which problem is this PR solving?
When bundling with
rollup
, the compiled files from the ESM build are used. When the bundle is run,require
is not defined because it's ESM - also the file it tries to require is not there since it's a bundle now.This is the case because we have a workaround in the
HttpExporterTransport
to lazy load a file that requireshttp
until we actually export. We need this workaround to ensure that the@opentelemetry/instrumentation-http
package can properly wrap everything - I'm not sure exactly how much of that is actually needed so I'll follow up with some more investigation after we get this fix in.This PR changes the
require()
to anawait import()
, which compiles torequire()
wrapped in aPromise.resolve()
for CJSimport()
for esm/esnextThese types of problems are actually prime candidates to test when we start working on
While this PR does not add any additional tests, it will unblock bundling with
rollup
for now. We should, however, get started on #4744 eventually to have this tested in an automated manner.Type of change
How Has This Been Tested?