Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
13
contributors
Commits on Mar 28, 2025
-
ref(browser/core): Move all log flushing logic into clients (#15831)
I experimented with a bunch of different approaches to register log flushing implementations, but I found the cleanest and most performant solution was to have log flushing logic live in clients. This refactors the browser client to do that, and adds tests for all of our flushing logic everywhere. The bundle size increase is not ideal, but I recognize we have no choice. After this gets merged in, I'll add the console logging integration to core. I'll also add some quick integrations for pino and winston.
-
Merge pull request #15914 from getsentry/master
[Gitflow] Merge master into develop
Commits on Mar 31, 2025
-
ref: Bump es-compatibility to ES2022 for node-based packages (#15926)
In preparation for OpenTelemetry v2, which targets ES2022, we bump the checks to ES2022 for node-based packages.
-
fix(cjs): Use
moduleinstead ofrequirefor CJS check (#15927)As `require` is supported in ESM as well from [Node 20.19.0](https://nodejs.org/en/blog/release/v20.19.0) onwards, the check does not work anymore. However, `module` is not available in ESM. Also mentioned in this comment: #14202 (comment) [Node: Compatibility with CommonJS](https://nodejs.org/docs/latest-v15.x/api/esm.html#esm_interoperability_with_commonjs) [Bun: Using require](https://bun.sh/docs/runtime/modules#using-require)
-
feat: Don't truncate error messages (#15818)
Ref getsentry/projects#837 for for not truncating error messages and letting relay do that. Kinda undoes #8593 Should be merged after #15819 because otherwise, we keep humongous strings in memory.
Commits on Apr 1, 2025
-
ref(core): Improve URL parsing utilities (#15882)
The bottleneck of many of the tasks written down in our Node SDK performance improvement task #15861 is `parseUrl`, defined here: https://github.com/getsentry/sentry-javascript/blob/3d63621714b31c1ea4c2ab2d90d5684a36805a43/packages/core/src/utils-hoist/url.ts#L17 We created #15767 to track removal of `parseUrl`. See more details in the GH issue. While working on tasks for #15767, I initially PR'd #15768, which introduced a `parseStringToURL` method as a replacement for `parseUrl`. While trying to implement that method though I realized `parseStringToURL` has a lot of downsides. This PR removes `parseStringToURL` in favor of a new `parseStringToURLObject`. Given `parseStringToURL` was never exported by the core SDK, this is not a breaking change. To understand `parseStringToURLObject`, let's first look at it's method signature: ```ts function parseStringToURLObject(url: string, urlBase?: string | URL | undefined): URLObject | undefined ``` `parseStringToURLObject` takes a string URL and turns it into a `URLObject`, that is typed like so: ```ts type RelativeURL = { isRelative: true; pathname: URL['pathname']; search: URL['search']; hash: URL['hash']; }; type URLObject = RelativeURL | URL; ``` the JavaScript URL built-in does not handle relative URLs, so we need to use a separate object to to track relative URLs. Luckily it's pretty small surface area, we only need to worry about `pathname`, `search`, and `hash`. For ease of usage of this function, I also introduced a `isURLObjectRelative` helper. This will make sure that users can handle both relative and absolute URLs with ease. Given `packages/core/src/fetch.ts` was using `parseStringToURL`, I refactored that file to use `parseStringToURLObject`. The change feels way better to me, much easier to read and understand what is going on.
-
build(profiling-node): Fix output directory & caching (#15945)
This used to build into `/lib` which is not covered by nx (it was changed there but slightly incorrectly, covering `/build/lib` instead of `/lib`). But overall, the way to go here is to just use our standard structure, which is `build/`, then this should all just work :D
Commits on Apr 2, 2025
-
fix(remix): Remove mentions of deprecated
ErrorBoundarywrapper (#1……5930) Since we dropped support for Remix v1, we're not wrapping Remix `root`s with `ErrorBoundary` anymore. Fixes https://github.com/orgs/getsentry/projects/31/views/19?pane=issue&itemId=103941554&issue=getsentry%7Csentry-javascript%7C15883 Docs PR: getsentry/sentry-docs#13170
-
chore(tests): Fix coverage file exclusions (#15944)
When running some unit tests locally, I noticed that the coverage summary contained files like `vite.config.ts` or `.eslintrc` as well as transpiled code in `build`. These files shouldn't be in the coverage reports and neither have an influence on the overall coverage score.
-
feat(browser): Add
http.redirect_countattribute to `browser.redire……ct` span (#15943) Adds an `http.redirect_count` attribute to `browser.redirect` spans. The count is taken from the `navigation` performance entry and it describes the number of times a redirect happened. Two caveats: - we can't detect more about redirects (e.g. the location the browser was redirected to) - this only works for same-origin redirects. [According to MDN](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming/redirectCount#value), cross-origin redirects are not taken into account.
-
ref(browser): Temporarily add
sentry.previous_tracespan attribute (#……15957) Temporarily add a span attribute for the previous trace to get trace links working in the EAP-based trace view. This needs to be removed once EAP properly supports span links.
-
Commits on Apr 3, 2025
-
feat(nuxt): Add nuxt release registry craft entry (#15962)
Turns out we never added the release registry entry for nuxt. The corresponding [folder exists in the release registry repo](https://github.com/getsentry/sentry-release-registry/tree/master/packages/npm/%40sentry/nuxt).
-
feat(nestjs): Add nestjs release registry craft entry (#15963)
Should wait on getsentry/sentry-release-registry#187 before merging.
-
feat(tanstackstart-react): Add tanstackstart-react to release registr…
…y craft entry (#15964) Corresponding entry in sentry-release-registry: https://github.com/getsentry/sentry-release-registry/tree/master/packages/npm/%40sentry/tanstackstart-react
-
-
feat(nuxt): Base decision on source maps upload only on Nuxt source m…
…ap settings (#15859) There is a total of 6 settings in Nuxt where you can disable/enable your source maps. This is not only difficult to understand when writing and maintaining the logic for this. It may also be hard to debug stuff for users.  There is this discussion around Nuxt source maps: #15028 And this issue: #15160 A problem with the current setup was not only the difficulty to understand all of this but also it sometimes just overwrote stuff you didn't want it to. Like in the default case of Nuxt, `sourcemap.server` is `true`, but as `nitro.rollupConfig.output.sourcemap` is always undefined, Sentry would overwrite this setting to `'hidden'`, even though the source maps were enabled already. --- The only two relevant options in Nuxt are the [root-level sourcemap options](https://nuxt.com/docs/guide/going-further/debugging#sourcemaps). Those settings will propagate to nitro, vite and rollup. As we overwrite the source maps setting if the setting is undefined, only the basic Nuxt source map settings (linked above) are taken into account for that from now on.
-
feat(core): Add
consoleLoggingIntegrationfor logs (#15955)Adds `consoleLoggingIntegration` integration that takes calls to `console.X` and flushes them as logs. For now this is an opt-in integration. We can evaluate it's default status at a later point. ```js import * as Sentry from '@sentry/browser'; // or any other supported sdk Sentry.init({ // send console.log, console.error, and console.warn calls as logs to Sentry integrations: [Sentry.consoleLoggingIntegration({ levels: ['log', 'error', 'warn'] })], }); ``` ## Notes In general we have inconsistencies with console instrumentation across our different SDKs. - In browser we have console instrumentation as part of the `Breadcrumbs` integration. - In node we have console instrumentation that generates breadcrumbs in the `Console` integration - In core we have console instrumentation, which generates errors and messages via the `CaptureConsole` integration For now because logs are experimental, making it a standalone integration feels fine to me. As we get closer to GA status for logs (and there is a distinct path for breadcrumbs) we should evaluate how all of our console integrations are structured. -
feat(react-router): Add
sentryHandleRequest(#15787)Co-authored-by: Luca Forstner <luca.forstner@sentry.io>
-
-
Merge pull request #15967 from getsentry/prepare-release/9.11.0
meta: Update CHANGELOG for 9.11.0
-
There are no files selected for viewing
This file was deleted.
This file was deleted.