chore(opentelemetry): Add worker as export | sort exports#21859
chore(opentelemetry): Add worker as export | sort exports#21859JPeer264 wants to merge 2 commits into
Conversation
JPeer264
requested review from
andreiborza and
mydea
and removed request for
a team
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| "node": { | ||
| "import": "./build/esm/index.js", | ||
| "require": "./build/cjs/index.js" | ||
| }, | ||
| "require": { | ||
| "node": { | ||
| "types": "./build/types/index.d.ts", | ||
| "default": "./build/cjs/index.js" | ||
| }, | ||
| "browser": { | ||
| "types": "./build/types/index.d.ts", | ||
| "default": "./build/cjs/index.browser.js" | ||
| }, | ||
| "types": "./build/types/index.d.ts", | ||
| "default": "./build/cjs/index.js" | ||
| "worker": { | ||
| "import": "./build/esm/index.js", | ||
| "require": "./build/cjs/index.js" | ||
| }, | ||
| "browser": { | ||
| "import": "./build/esm/index.browser.js", | ||
| "require": "./build/cjs/index.browser.js" |
There was a problem hiding this comment.
Bug: The exports order in package.json is incorrect. Generic import/require conditions appear before the browser condition, causing bundlers to select the Node.js build for browser environments.
Severity: HIGH
Suggested Fix
Reorder the exports conditions in package.json to place specific environment conditions (browser, worker, node) before the generic import and require fallbacks. This ensures that environment-specific bundlers select the correct entry point. For example, the browser condition should be evaluated before the top-level import condition.
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-L34
Potential issue: The `exports` map in `package.json` has an incorrect condition order.
Generic conditions `import` and `require` are listed before specific environment
conditions like `browser`. According to Node.js resolution rules, the first matching
condition is used. This means browser bundlers will match the generic `import` condition
and receive the Node.js-specific build (`./build/esm/index.js`). This build imports
`node:async_hooks`, which is not available in browsers, leading to runtime errors. The
intended browser-specific build, which provides a safe stub for Node.js APIs, will be
ignored.
Did we get this right? 👍 / 👎 to inform future reviews.
There was a problem hiding this comment.
TIL. Didn't know that matters
| "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.json exports 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
2 participants
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)