feat(core): split exports by browser/server for bundle size#20435
feat(core): split exports by browser/server for bundle size#20435
Conversation
isaacs
force-pushed
the
isaacschlueter/split-server-browser-core-exports
branch
6 times, most recently
from
143a2a5 to
1494709
Compare
size-limit report 📦
|
isaacs
force-pushed
the
isaacschlueter/split-server-browser-core-exports
branch
5 times, most recently
from
d5dddbf to
8eba1e9
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
isaacs
force-pushed
the
isaacschlueter/split-server-browser-core-exports
branch
from
8eba1e9 to
8ea4f5c
Compare
isaacs
force-pushed
the
isaacschlueter/split-server-browser-core-exports
branch
from
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
isaacs
force-pushed
the
isaacschlueter/split-server-browser-core-exports
branch
from
787f44b to
7076f7c
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.
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
isaacs
force-pushed
the
isaacschlueter/split-server-browser-core-exports
branch
from
7076f7c to
e2cf052
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
isaacs
force-pushed
the
isaacschlueter/split-server-browser-core-exports
branch
from
e2cf052 to
67bf5c4
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| new InstrumentationNodeModuleDefinition('http', ['*'], wrapHttp), | ||
| new InstrumentationNodeModuleDefinition('https', ['*'], wrapHttps), | ||
| ]; | ||
| } |
There was a problem hiding this comment.
Bug: The SentryHttpInstrumentation no longer provides an unwrap function, meaning diagnostic channel subscriptions are not cleaned up when the instrumentation is disabled via disable().
Severity: LOW
Suggested Fix
Reintroduce the unwrap callback as the fourth parameter to the InstrumentationNodeModuleDefinition constructor. Inside this callback, call unsubscribe() for all diagnostic channels that were subscribed to in the init function, mirroring the cleanup logic from the previous version of the code.
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/node-core/src/integrations/http/SentryHttpInstrumentation.ts#L242-L245
Potential issue: The refactored `SentryHttpInstrumentation` omits the `unwrap` callback
when defining the instrumentation. Previously, this callback was used to `unsubscribe()`
from diagnostic channels like `HTTP_ON_CLIENT_REQUEST`. Without this cleanup logic, if
`instrumentation.disable()` is ever called, the subscriptions will persist. This causes
handlers to continue firing, leading to the creation of breadcrumbs and spans even after
the instrumentation is supposedly disabled. This is a functional regression from the
previous implementation which correctly managed the subscription lifecycle.
Did we get this right? 👍 / 👎 to inform future reviews.
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 67bf5c4. Configure here.
| // Skip if tracing is suppressed (e.g., inside Sentry.suppressTracing()) | ||
| if (getCurrentScope().getScopeData().sdkProcessingMetadata[SUPPRESS_TRACING_KEY] === true) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
suppressTracing skips breadcrumbs and trace propagation entirely
Medium Severity
The SUPPRESS_TRACING_KEY check on the current scope causes the entire onHttpClientRequestCreated handler to return early, skipping not just span creation but also breadcrumbs and trace propagation header injection. The documented behavior of suppressTracing is "ensuring no spans are generated inside of it," but this implementation also suppresses breadcrumbs for HTTP requests made within suppressTracing() callbacks. While suppressing everything is correct for Sentry's own internal outgoing requests, user-facing suppressTracing() usage would unexpectedly lose HTTP breadcrumbs.
Reviewed by Cursor Bugbot for commit 67bf5c4. Configure here.
| return { | ||
| [HTTP_ON_CLIENT_REQUEST]: onHttpClientRequestCreated, | ||
| }; | ||
| } |
There was a problem hiding this comment.
Missing unit tests for new HTTP instrumentation code
Low Severity
This feat PR introduces substantial new production code in packages/core/src/integrations/http/ (client-patch, client-subscriptions, get-outgoing-span-data, inject-trace-propagation-headers, merge-baggage, add-outgoing-request-breadcrumb) but does not include any unit or integration tests specifically covering this new HTTP instrumentation logic. Existing E2E tests were updated to match new assertion values, but the new code paths (patching, breadcrumb creation, trace injection, error handling) lack dedicated test coverage. Per the review rules, feat PRs are expected to include at least one integration or E2E test for new behavior.
Additional Locations (1)
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 67bf5c4. Configure here.
timfish
left a comment
timfish
left a comment
There was a problem hiding this comment.
I looked through most of the changed files.
I guess this doesn't deprecate the old root exports yet?
| expect.objectContaining({ | ||
| data: expect.objectContaining({ | ||
| 'sentry.op': 'http.client', | ||
| 'sentry.origin': 'auto.http.otel.http', |
There was a problem hiding this comment.
these seem like unrelated changes, a different PR leaking into this? 😅
| "include": ["src/**/*"], | ||
|
|
||
| "compilerOptions": { | ||
| "module": "esnext", |
There was a problem hiding this comment.
is this related to this change/required here?
| "include": ["src/**/*", "test/loader.js"], | ||
|
|
||
| "compilerOptions": { | ||
| "module": "esnext", |
There was a problem hiding this comment.
is this required for this change here?
|
|
||
| const getExpressExport = (express: ExpressModuleExport): ExpressExport => | ||
| hasDefaultProp(express) ? express.default : (express as ExpressExport); | ||
| import { getDefaultExport } from '../../utils/get-default-export'; |
There was a problem hiding this comment.
also likely leaked in from another PR?
3 participants
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