feat(core): split exports by browser/server for bundle size#20435
feat(core): split exports by browser/server for bundle size#20435
Conversation
143a2a5 to
1494709
Compare
size-limit report 📦
|
14d99a8 to
d5dddbf
Compare
This was implemented for the portable Express integration, but others will need the same functionality, so make it a reusable util.
Refactor the `node:http` outgoing request instrumentation so that it can be applied to non-Node.js environments by patching the http module. Also, refactor so that the diagnostics_channel and monkeypatching paths can share code, and so that light and normal node-core instrumentations can share more of the functionality as well. To facilitate this, some portable minimal types are vendored in from the `node:http` module.
d5dddbf to
8eba1e9
Compare
8eba1e9 to
8ea4f5c
Compare
8ea4f5c to
787f44b
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs, in `@sentry/core` where they can be easily shared across runtimes. Integration may require updating our `tsconfig` settings so that tsc knows it is allowed to look on `package.json` exports. fix: #20434 fix: JS-2243
787f44b to
7076f7c
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 7076f7c. Configure here.
| export { instrumentFetchRequest, _INTERNAL_getTracingHeadersForFetchRequest } from './fetch'; | ||
| export { trpcMiddleware } from './trpc'; | ||
| export { wrapMcpServerWithSentry } from './integrations/mcp-server'; | ||
| export { captureFeedback } from './feedback'; |
There was a problem hiding this comment.
Server-specific utilities unnecessarily included in browser exports
Low Severity
Several server-oriented utilities like trpcMiddleware, wrapMcpServerWithSentry, and handleTunnelRequest are placed in shared-exports.ts rather than server-exports.ts. This means they are available (and included in the module graph) via @sentry/core/browser, working against the PR's stated goal of reducing browser bundle size. While tree-shaking may eliminate them if unused, placing them in server-exports.ts would make the conceptual split cleaner and reduce the surface area of @sentry/core/browser. Flagging this because the PR description explicitly states this change is for bundle size, per review rules about large bundle size increases in browser packages.
Additional Locations (1)
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 7076f7c. Configure here.
| const onHttpClientRequestCreated: ChannelListener = (data: unknown): void => { | ||
| const clientOptions = getConfig(); | ||
| const { | ||
| errorMonitor = 'error', |
There was a problem hiding this comment.
Default errorMonitor silently swallows Node.js request errors
Medium Severity
The errorMonitor option defaults to the string 'error' when not provided. This means request.on('error', handler) adds a real error handler that prevents Node.js's default "crash on unhandled error" behavior. If patchHttpModuleClient or patchHttpsModuleClient is called without passing the errorMonitor option (which should be EventEmitter.errorMonitor from node:events), HTTP request errors are silently consumed by the Sentry handler, potentially hiding real errors from users. While node-core correctly passes the symbol, the public API's default is misleading.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 7076f7c. Configure here.


Note: stacked atop #20393, only the top commit needs review. Land that before this one.
Split the exports from
@sentry/coreinto three options:@sentry/core, the default (unchanged)@sentry/core/browser, containing only shared and browser-specificfunctionality, nothing server-specific.
@sentry/core/server, containing only shared and server-specificfunctionality, nothing browser-specific.
This allows us to make the bundle sizes quite a bit smaller in our
browser SDKs where this is important, while adding more functionality to
our server-specific SDKs, in
@sentry/corewhere they can be easilyshared across runtimes.
fix: #20434
fix: JS-2243