Deprecations in 7.x

To fix most of the deprecations on 7.x, you can use the @sentry/migr8 codemod to automatically update your SDK usage. @sentry/migr8 requires Node 18+.

npx @sentry/migr8@latest

Our migration tool will let you select which updates to run, and automatically update your code. In some cases, we cannot automatically change code for you. These will be marked with a TODO(sentry) comment instead. Make sure to review all code changes after running @sentry/migr8!

List of Deprecations

The following is a list of the most important deprecations that happened in 7.x. Please see the detailed migration docs on GitHub for a comprehensive list of all deprecations.

Deprecate class-based integrations

Deprecation introduced in 7.100.0.

In v7, integrations are classes and can be added as e.g. integrations: [new Sentry.Integrations.ContextLines()]. In v8, integrations will not be classes anymore, but instead functions. Both the use as a class, as well as accessing integrations from the Integrations.XXX hash, is deprecated in favor of using the new functional integrations

• for example, new Integrations.LinkedErrors() becomes linkedErrorsIntegration().

The following list shows how integrations should be migrated:

Deprecated BrowserTracing integration

Deprecation introduced in 7.100.0.

The BrowserTracing integration, together with the custom routing instrumentations passed to it, are deprecated in v8.

Instead, you should use Sentry.browserTracingIntegration().

 import * as Sentry from "@sentry/svelte";

 Sentry.init({
   dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
-  integrations: [new Sentry.BrowserTracing()],
+  integrations: [Sentry.browserTracingIntegration()],
 });

Deprecate getIntegration() and getIntegrationById()

Deprecation introduced in 7.94.0.

This deprecates getIntegrationById() and getIntegration() on the client. Instead, use getIntegrationByName(). You can optionally pass an integration generic to make it easier to work with.

const replay = getClient().getIntegrationByName<Replay>("Replay");

Deprecate Hub

Deprecation introduced in 7.110.0.

The Hub has been a very important part of the Sentry SDK API up until now. Hubs were the SDK's "unit of concurrency" to keep track of data across threads and to scope data to certain parts of your code. Because it is overly complicated and confusing to power users, it is going to be replaced by a set of new APIs: the "new Scope API".

Scopes have existed before in the SDK but we are now expanding on them because we have found them powerful enough to fully cover the Hub API.

If you are using the Hub right now, see the following table on how to migrate to the new API:

The Hub constructor is also deprecated and will be removed in the next major version. If you are creating Hubs for multi-client use like so:

// OLD
const hub = new Hub();
hub.bindClient(client);
makeMain(hub);

instead initialize the client as follows:

// NEW
Sentry.withIsolationScope(() => {
  Sentry.setCurrentClient(client);
  client.init();
});

If you are using the Hub to capture events like so:

// OLD
const client = new Client();
const hub = new Hub(client);
hub.captureException();

instead capture isolated events as follows:

// NEW
const client = new Client();
const scope = new Scope();
scope.setClient(client);
scope.captureException();

Deprecate addGlobalEventProcessor in favor of addEventProcessor

Deprecation introduced in 7.85.0.

Instead of using addGlobalEventProcessor, you should use addEventProcessor which does not add the event processor globally, but to the current client.

For the vast majority of cases, the behavior of these should be the same. Only in the case where you have multiple clients will this differ - but you'll likely want to add event processors per-client then anyhow, not globally.

In v8, we will remove the global event processors overall, as that allows us to avoid keeping global state that is not necessary.

Deprecate configureScope in favor of using getCurrentScope()

Deprecation introduced in 7.89.0.

Instead of updating the scope in a callback via configureScope(), you should access it via getCurrentScope() and configure it directly:

Sentry.getCurrentScope().setTag("xx", "yy");

Deprecate pushScope & popScope in favor of withScope

Deprecation introduced in 7.89.0.

Instead of manually pushing/popping a scope, you should use Sentry.withScope(callback: (scope: Scope)) instead.

Deprecate arguments for startSpan() APIs

Deprecation introduced in 7.93.0.

In v8, the API to start a new span will be reduced from the currently available options. Going forward, only these arguments will be passable to startSpan(), startSpanManual() and startInactiveSpan():

• name
• attributes
• origin
• op
• startTime
• scope

Deprecate startTransaction() & span.startChild()

Deprecation introduced in 7.93.0.

In v8, the old performance API startTransaction() (and hub.startTransaction()), as well as span.startChild(), will be removed. Instead, use the new performance APIs:

• startSpan()
• startSpanManual()
• startInactiveSpan()

Deprecated transactionContext passed to tracesSampler

Deprecation introduced in 7.100.0.

Instead of an transactionContext being passed to the tracesSampler callback, the callback will directly receive name and attributes going forward. You can use these to make your sampling decisions, while transactionContext will be removed in 8.x. Note that the attributes are only the attributes at span creation time, and some attributes may only be set later during the span lifecycle (and thus not be available during sampling).

Deprecate scope.getSpan() and scope.setSpan()

Deprecation introduced in 7.93.0.

Instead, you can get the currently active span via Sentry.getActiveSpan(). Setting a span on the scope happens automatically when you use the new performance APIs startSpan() and startSpanManual().

Deprecate scope.getTransaction() and getActiveTransaction()

Deprecation introduced in 7.93.0.

Instead, you should not rely on the active transaction, but just use startSpan() APIs, which handle this for you.