Failed to resolve components of "otlp-exporter-base" from "exporter-trace-otlp-http"

[kostz]

What happened?

Steps to Reproduce

Initialisation of OTLPLogExporter is failing, see the application illustrating the problem here https://github.com/kostz/otlp-logging-browser-demo

Expected Result

Build successful

Actual Result

Build unsuccessful

🚨 Build failed.

@parcel/core: Failed to resolve '@opentelemetry/otlp-exporter-base/browser-http' from 
'./node_modules/@opentelemetry/exporter-logs-otlp-http/build/esm/platform/browser/OTLPLogExporter.js'

Additional Details

• It seems that problem relates to this PR feat(exporters)!: collapse base classes into one #5031 where base classes were heavily redesigned (cc: @pichlermarc )
• Everything works fine with opentelemetry v0.43.0 (with this package.json)

OpenTelemetry Setup Code

index.js

package.json

package.json

Relevant log output

🚨 Build failed.

@parcel/core: Failed to resolve '@opentelemetry/otlp-exporter-base/browser-http' from 
'./node_modules/@opentelemetry/exporter-logs-otlp-http/build/esm/platform/browser/OTLPLogExporter.js'

Operating System and Version

MacOS 15.3

Runtime and Version

Node.js v23.7.0

[JamieDanielson]

Thank you for reporting and providing a repro app! It looks like this issue actually occurs on logs, metrics, and traces exporters with a certain setup. I was looking into this to see what ways I could reproduce it.

So we get this error Unable to resolve module @opentelemetry/otlp-exporter-base/browser-http, which looks like it should be found in the exports for @opentelemetry/otlp-exporter-base. The path should resolve based on these exports, and in node_modules update the import to import { createLegacyOtlpBrowserExportDelegate } from '@opentelemetry/otlp-exporter-base/index-browser-http';.

If I try running a file without a transpilation step, like npx ts-node app/otel.tsx, it works fine. When it comes time to transpile using something like parcel or babel, it seems an extra configuration option may be necessary to take advantage of the package exports. Still investigating what that config may be... 🤔

[JamieDanielson]

After some further digging, it does seem like different bundlers / build tools need to be configured to enable using the exports from package.json. In this case, for parcel, there is added support starting with Parcel v2.9.0, but it requires a configuration to opt-in.

{
  "@parcel/resolver-default": {
    "packageExports": true
  }
}

[JamieDanielson]

Sorry to be clear, this needs to get added into your package.json file, not the .parcelrc file.

➜  otlp-logging-browser-demo git:(main) ✗ diff -u package.json.orig package.json     
--- package.json.orig   2025-02-13 17:49:49
+++ package.json        2025-02-13 17:49:54
@@ -8,6 +8,9 @@
   "scripts": {
     "start": "parcel index.html"
   },
+  "@parcel/resolver-default": {
+    "packageExports": true
+  },

[trentm]

A fix (I think) on the OTel side would be this change to otlp-exporter-base/package.json:

% diff -u package.json.orig package.json
--- package.json.orig	2025-02-13 14:36:26
+++ package.json	2025-02-13 14:38:38
@@ -6,6 +6,9 @@
   "module": "build/esm/index.js",
   "esnext": "build/esnext/index.js",
   "types": "build/src/index.d.ts",
+  "browser": {
+    "./browser-http": "./build/esm/index-browser-http.js"
+  },
   "exports": {
     ".": {
       "module": "./build/esm/index.js",

This tells any resolvers where to find @opentelemetry/otlp-exporter-base/browser-http if they (a) don't grok "exports" yet and (b) use the "browser" main field -- which parcel does, and I guess all(?) bundlers will (per https://github.com/defunctzombie/package-browser-field-spec).

[trentm]

The core and contrib otel js repos use "exports" in the following packages:

[~/src/opentelemetry-js (git:main)] % rg '"exports"' -g package.json
semantic-conventions/package.json
9:  "exports": {

api/package.json
15:  "exports": {

experimental/packages/shim-opencensus/package.json
7:  "exports": {

experimental/packages/otlp-exporter-base/package.json
9:  "exports": {

[~/src/opentelemetry-js-contrib (git:main)] % rg '"exports"' -g package.json
metapackages/auto-instrumentations-node/package.json
16:  "exports": {

So I guess any parcel@2 user with the default parcel configuration will break if they attempt to use a code path that uses one of these exports. The use of "exports" in otlp-exporter-base in tag: v1.29.0, tag: experimental/v0.56.0 (released: "0.56.0": "2024-12-04T16:33:27.244Z") made this the common case I guess.

My guess is the next most likely case is @opentelemetry/semantic-conventions/incubating. Though we discourage directly using that it is still possible that 3rd-party instrumentations use it.

Personally I've not seen usage of @opentelemetry/api/experimental in the wild.

[JamieDanielson]

This tells any resolvers where to find @opentelemetry/otlp-exporter-base/browser-http if they (a) don't grok "exports" yet and (b) use the "browser" main field -- which parcel does, and I guess all(?) bundlers will

Some of the testing I've been looking at locally is with an expo app, which is react-native. When I make the change to my metro.config.js file to include config.resolver.unstable_enablePackageExports = true;, things work as expected with the current published package. With the added browser section, it still seems to work, but I notice errors in my logs. I'm not sure yet if there is a way to silence those logs without losing others, but this could potentially be a problem for folks 🤔

 WARN  Attempted to import the module "myapp/node_modules/@opentelemetry/otlp-exporter-base/build/esm/index-browser-http.js" which is not listed in the "exports" of "myapp/node_modules/@opentelemetry/otlp-exporter-base" under the requested subpath "./build/esm/index-browser-http.js". Falling back to file-based resolution. Consider updating the call site or asking the package maintainer(s) to expose this API.

[trentm]

We'd want to be sure that a bundler that does support "exports" wouldn't be broken by this... or I guess also the "expo" case that results in added warnings.

If the entry-point in @opentelemetry/otlp-exporter-base works for a few other bundlers (e.g. rollup, webpack, esbuild, and I guess Metro now), then we probably should NOT add this workaround for parcel@2 and instead just document usage of https://parceljs.org/features/dependency-resolution/#enabling-package-exports

[kostz]

Thanks @trentm , @JamieDanielson for prompt feedback, for now I'll downgrade to v0.43 where this is still working out of the box, but seems later it can be a challenge for us to upgrade to latest upstream,

so looking forward where you decide to go with this, like documentation line seems to be enough, and also wondering if something similar may happen with another bundlers, like a webpack, but seems @trentm mentioned that it works for webpack