Skip to content

Files

Latest commit

 

History

History
67 lines (51 loc) · 3.13 KB

browser-other-changes.mdx

File metadata and controls

67 lines (51 loc) · 3.13 KB

Removal of @sentry/replay package

The @sentry/replay package is no longer required. Instead you can import the relevant methods directly from your SDK. In addition to this, the integration is now functional instead of class-based.

-import { Replay } from '@sentry/replay';
-
 Sentry.init({
   dsn: '___PUBLIC_DSN___',
   integrations: [
-    new Replay(),
+    Sentry.replayIntegration(),
   ],
 });

Change of Replay default options (unblock and unmask)

The Replay options unblock and unmask now have [] as default value. This means that if you want to use these options, you have to explicitly set them like this:

Sentry.init({
  integrations: [
    Sentry.replayIntegration({
      unblock: [".sentry-unblock, [data-sentry-unblock]"],
      unmask: [".sentry-unmask, [data-sentry-unmask]"],
    }),
  ],
});

Removal of makeXHRTransport transport

The xhr transport via makeXHRTransport transport has been removed. Only makeFetchTransport is available now. This means that the Sentry SDK requires the fetch API to be available in the environment.

<PlatformSection notSupported={['javascript.wasm', 'javascript.capacitor', 'javascript.azure-functions']}>

Removal of the Offline integration

The Offline integration has been removed in favor of the offline transport wrapper

Removal of wrap export

The Sentry.wrap export has been removed. There is no replacement API.

Updated behaviour of tracePropagationTargets in the browser

We updated the behaviour of the SDKs when no tracePropagationTargets option was defined. As a reminder, you can provide a list of strings or RegExes that will be matched against URLs to tell the SDK, to which outgoing requests tracing HTTP headers should be attached to. These tracing headers are used for distributed tracing.

Previously, on the browser, when tracePropagationTargets were not defined, they defaulted to the following: ['localhost', /^\/(?!\/)/]. This meant that all request targets to that had "localhost" in the URL, or started with a / were equipped with tracing headers. This default was chosen to prevent CORS errors in your browser applications. However, this default had a few flaws.

Going forward, when the tracePropagationTargets option is not set, tracing headers will be attached to all outgoing requests on the same origin. For example, if you're on https://example.com/ and you send a request to https://example.com/api, the request will be traced (ie. will have trace headers attached). Requests to https://api.example.com/ will not, because it is on a different origin. The same goes for all applications running on localhost.

When you provide a tracePropagationTargets option, all of the entries you defined will now be matched be matched against the full URL of the outgoing request. Previously, it was only matched against what you called request APIs with. For example, if you made a request like fetch("/api/posts"), the provided tracePropagationTargets were only compared against "/api/posts".