Uh oh!
There was an error while loading. Please reload this page.
chore(opentelemetry): Add worker as export | sort exports - #21859
Conversation
Uh oh!
There was an error while loading. Please reload this page.
| "import": "./build/esm/index.js", | ||
| "require": "./build/cjs/index.js", |
There was a problem hiding this comment.
would this not lead to these being picked over the node/browser/worker ones? 🤔 should these not be below those to be picked as fallbacks...?
There was a problem hiding this comment.
basically what the clanker found below :D
There was a problem hiding this comment.
Oh shoot, I wasn't aware that there is a strict order (I thought in JavaScript there is no way to guarantee the order of how it is written)
There was a problem hiding this comment.
moved import and require after all specific imports
size-limit report 📦
|
| }, | ||
| "types": "./build/types/index.d.ts", | ||
| "default": "./build/esm/index.js" | ||
| "types": "./build/types/index.d.ts", |
There was a problem hiding this comment.
Bug: The single types field in package.json provides Node.js types to browser environments, causing a type-runtime mismatch and leading to runtime errors.
Severity: HIGH
Suggested Fix
Revert the package.jsonexports to use per-environment types fields. Each conditional export (e.g., for browser and node) should have its own types entry pointing to the correct type definition file for that specific environment. This will likely require generating separate type definitions for the browser entrypoint.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/opentelemetry/package.json#L21
Potential issue: The `package.json` `exports` map was updated to use a single, top-level
`types` field. This field points to type definitions generated exclusively from the
Node.js entrypoint (`src/index.ts`). However, the package also provides a separate
browser-specific entrypoint (`src/index.browser.ts`) with different exports and
implementations. This creates a type-runtime mismatch for users in a browser
environment. TypeScript will indicate that Node-specific exports, like the full
`SentryAsyncLocalStorageContextManager` class, are available. At runtime, the
browser-specific stub implementation is used, which lacks the methods of the Node
version, leading to runtime errors like "method is not a function".
There was a problem hiding this comment.
This is the only types file we have
There was a problem hiding this comment.
But in general not a bad comment
👋 @mydea, @Lms24, @andreiborza — Please review this PR when you get a chance! |
| "import": "./build/esm/index.js", | ||
| "require": "./build/cjs/index.js" |
There was a problem hiding this comment.
l: I think we can add a default condition around these, wdyt?
I recently learned this is considered best practise (#21472)
There was a problem hiding this comment.
Very interesting. First I thought this is the same, but there is indeed some difference: https://nodejs.org/api/packages.html#conditional-exports
Maybe worth to add it everywhere just in case 🤔
Lms24
commented
Jul 6, 2026
(Sorry for the late review!) |
Uh oh!
There was an error while loading. Please reload this page.
In the future we need to import from
@sentry/opentelemetry. As there is now abrowserexport we go into that path, based on the wrangler's build preferences. As of now, the browser entrypoint is only here to print a warning - which would also happen on Cloudflare.In order to use the correct entrypoint in Cloudflare the
workerentry has been added.On top I also sorted the exports to match the other
package.jsons. Instead ofimport -> node -> defaultit is nownode -> import(so it is one depth less)