fix(api): esnext export condition is more specific than module

[cjpearson]

Which problem is this PR solving?

I'm building an application with rollup. I want to use the esnext export from @opentelemetry/api, so I add 'esnext' as an export condition. However, since the 'module' condition is always used and in the package.json it occurs before the esnext condition, the module condition will always match.

Since the esnext condition is more specific, I think it makes sense to have it occur before the module condition.

https://nodejs.org/api/packages.html#packages_conditional_exports

Short description of the changes

Move esnext export condition to the top in package.json, so that an esnext + module condition will resolve to the esnext directory.

Before
exportConditions: ['module', 'esnext'] => esm
exportConditions: ['module'] => esm

After
exportConditions: ['module', 'esnext'] => esnext
exportConditions: ['module'] => esm

Type of change

Please delete options that are not relevant.

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

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

• Local testing

Checklist:

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.04%. Comparing base (56df3c0) to head (dce0967).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5458   +/-   ##
=======================================
  Coverage   95.04%   95.04%           
=======================================
  Files         310      310           
  Lines        8008     8008           
  Branches     1616     1616           
=======================================
  Hits         7611     7611           
  Misses        397      397           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trentm]

@cjpearson Interestingly we were (separately) discussing dropping the build/esnext export... though that was about packages other than this @opentelemetry/api package, and in context of bumping the TypeScript transpilation target to ES2022 (#5393).

Can you show a repro, or at least your full rollup config? I'm not very familiar with the config settings involved in the various bundlers here.

Also, I'm curious what about the build/esnext output that you want/need vs. the current build/esm output. Thanks.

[cjpearson]

I wanted to use the esnext build to get the newer compilation target, since rollup also complains about the global this that is present in the esm build. So bumping the target for esm would be even better, but I thought this might work as a non-breaking solution.

I'm not actually using rollup directly, but rather through nuxt. I'll try and create a simple reproduction though.

[cjpearson]

I've created an example here: https://github.com/cjpearson/nuxt-otel-repro

Nuxt uses several plugins, so it's probably possible to narrow it down further if needed. But this app adds a single endpoint which imports trace from @opentelemetry/api and creates a span.

When building, rollup logs a bunch of warnings:

ℹ Building Nuxt Nitro server (preset: node-server, compatibility date: 2024-11-01)                                                                                                    
node_modules/@opentelemetry/api/build/esm/metrics/NoopMeter.js (16:17): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/metrics/NoopMeter.js (16:25): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/diag.js (16:14): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/diag.js (16:22): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/diag.js (32:21): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/diag.js (32:29): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/context.js (16:14): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/context.js (16:22): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/context.js (32:21): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/api/context.js (32:29): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/baggage/internal/baggage-impl.js (16:14): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/baggage/internal/baggage-impl.js (16:22): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/baggage/internal/baggage-impl.js (32:16): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/baggage/internal/baggage-impl.js (32:24): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/diag/ComponentLogger.js (16:14): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/diag/ComponentLogger.js (16:22): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/diag/ComponentLogger.js (32:21): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/diag/ComponentLogger.js (32:29): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/context/NoopContextManager.js (16:14): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/context/NoopContextManager.js (16:22): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/context/NoopContextManager.js (32:21): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
node_modules/@opentelemetry/api/build/esm/context/NoopContextManager.js (32:29): The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[cjpearson]

not stale

[cjpearson]

Hi @trentm, would it be possible to take another look at this?