---
title: "Migrate from 10.x to 11.x"
description: "Learn about migrating from Sentry JavaScript SDK 10.x to 11.x."
url: https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11/
---

# Migrate from 10.x to 11.x | Sentry for Effect

Version 11 of the Sentry JavaScript SDK focuses on better OpenTelemetry interoperability, more flexible instrumentation, and better out-of-the-box defaults. The biggest changes are:

* **OpenTelemetry interoperability:** The SDK no longer takes over your OpenTelemetry setup.
* **Instrumentation:** The instrumentations of the SDK now runs through [diagnostics channels](https://nodejs.org/api/diagnostics_channel.html#diagnostics-channel), which unlocks tracing on platforms like Vercel, Netlify and Cloudflare, but also runtimes like Bun and Deno.
* **Span streaming:** [Stream mode](https://docs.sentry.io/platforms/javascript/tracing/streamed-spans.md) is the new default, so spans no longer hit the size and volume limits of transactions.
* **Data collection:** `sendDefaultPii` is replaced by `dataCollection`, which controls each category of data separately and collects more by default ([Read more](https://blog.sentry.io/datacollection-control-panel/) about `dataCollection`)
* **Version support:** Node.js 20.19.0 is the new minimum. We also raised the minimum TypeScript version and the minimum versions of several frameworks.

We recommend that you upgrade to the most recent 10.x release first, because most of what v11 removes is already deprecated there.

Version 11 of the SDK requires Sentry self-hosted 26.4.2 or higher. Lower versions may continue to work, but are not supported. We recommend that you update self-hosted Sentry to the latest version.

## [Version Support Changes](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#version-support-changes)

Version 11 has new compatibility ranges for runtimes, frameworks, and libraries.

### [TypeScript](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#typescript)

The minimum required TypeScript version is **5.0.4**. The SDK no longer ships down-leveled types. Older TypeScript versions *may* continue to work, but no guarantees apply.

## [Data Collection](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#data-collection)

`sendDefaultPii` is replaced by `dataCollection`, which controls each category of collected data separately. Our blog post [The Data Collection Control Panel](https://blog.sentry.io/datacollection-control-panel/) covers the thinking behind it.

This is a behavior change, not a rename. In v10, an unset `sendDefaultPii` was restrictive. In v11, an unset `dataCollection` collects everything by default.

| Category              | v10 default (`sendDefaultPii` off) | v11 default          |
| --------------------- | ---------------------------------- | -------------------- |
| `userInfo`            | `false`                            | `true`               |
| `cookies`             | not collected                      | `true`               |
| `httpHeaders`         | request + response, PII scrubbed   | request + response   |
| `httpBodies`          | not collected (size only)          | all request/response |
| `urlQueryParams`      | `true`                             | `true`               |
| `genAI`               | inputs + outputs not collected     | inputs + outputs     |
| `databaseQueryData`   | `false`                            | `true`               |
| `stackFrameVariables` | `true`                             | `true`               |
| `frameContextLines`   | `7`                                | `5`                  |

If you set `sendDefaultPii: true`, remove it. The v11 default matches that behavior.

If you relied on the v10 default, set the baseline explicitly.

Sentry scrubs values whose key looks sensitive (e.g. `auth`, `token`, `secret`, `password`). The match runs on the key name, so treat it as best effort: a credential in a field that isn't named like one still reaches Sentry. Review your [data scrubbing](https://docs.sentry.io/platforms/javascript/guides/effect/data-management/sensitive-data.md) config for the categories v11 collects now, especially request and response bodies.

Keeping the v10 collection defaults

```js
Sentry.init({
  dataCollection: {
    userInfo: false,
    cookies: false,
    httpHeaders: {
      request: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
      response: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
    },
    httpBodies: [],
    urlQueryParams: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
    genAI: { inputs: false, outputs: false },
    databaseQueryData: false,
    graphQL: { document: false, variables: false },
  },
});
```

The `cookies`, `urlQueryParams`, and `httpHeaders` fields also accept `true`, `false`, `{ allow: string[] }`, or `{ deny: string[] }`.

Overriding a category for a single integration

The `include` options of `requestDataIntegration` stay an integration-level override. An explicit `false` keeps a category off the event, and an explicit `true` attaches it even when `dataCollection` has that category disabled. Any `allow` or `deny` filtering still applies, and a category that only `include` enables is filtered with the default denylist for sensitive values.

User IP address inference is now controlled by `dataCollection.userInfo`. To keep it for the data this integration collects, set `requestDataIntegration({ include: { ip: true } })`.

See the [`dataCollection` option](https://docs.sentry.io/platforms/javascript/guides/effect/configuration/options.md#dataCollection) for the full list of categories.

## [Logs and Metrics](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#logs-and-metrics)

The `enableLogs` and `enableMetrics` options were removed, including their `_experiments` variants. Logs and metrics are captured whenever you use their APIs (`Sentry.logger.*`, `Sentry.metrics.*`) or add a logging integration such as `consoleLoggingIntegration()`. The `_experiments.beforeSendMetric` callback moved to the top-level `beforeSendMetric` option.

```js
// Before
Sentry.init({
  enableLogs: true,
  _experiments: {
    enableMetrics: true,
    beforeSendMetric: (metric) => metric,
  },
});

// After
Sentry.init({
  beforeSendMetric: (metric) => metric,
});
```

## [Errors and Sessions](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#errors-and-sessions)

New defaults change which events carry a stack trace and how sessions are counted.

### [Stack Traces Are Attached by Default](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#stack-traces-are-attached-by-default)

`Sentry.captureMessage()` events, and non-`Error` values passed to `Sentry.captureException()`, now attach a synthetic stack trace that points to the call site. Set `attachStacktrace: false` to restore the previous behavior.

Two consequences are worth checking after you upgrade:

* **Issue grouping:** Sentry groups events with and without stack traces differently, so you may see new issue groups.
* **Release health:** Events with a stack trace count as errors, so a `captureMessage()` call marks the current session as errored. Crash-free session rate is not affected. For purely informational output, consider [Sentry Logs](https://docs.sentry.io/product/logs.md) instead.

### [Trace Propagation Matching Is Case-Insensitive](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#trace-propagation-matching-is-case-insensitive)

String and regular expression matching for `tracePropagationTargets` no longer depends on casing. In browsers this was especially surprising, because the URL is normalized with `new URL()` before matching, which lower-cases the origin. A target such as `'myApi.com'` could therefore never match a request to `https://myApi.com`.

```js
Sentry.init({
  // In a browser, neither of these matched `https://myApi.com` in v10. In v11 both do.
  tracePropagationTargets: ["myApi.com", /^https:\/\/myApi\.com/],
});
```

If you relied on case-sensitive matching to tell two targets apart, narrow the target with a more specific path. The `g` and `y` flags are ignored now, because they made matching stateful and a target like `/myApi\.com/g` matched only every other request.

## [Removed APIs](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#removed-apis)

The changes in this section detail deprecated APIs that are now removed.

### [All SDKs](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#all-sdks)

* `@sentry/core` exports only isomorphic code now. Browser-only exports live on `@sentry/core/browser` and server-only ones on `@sentry/core/server`, which keeps server code out of browser bundles. This only affects imports straight from `@sentry/core`, since the platform SDKs re-export as before. TypeScript reports it as `has no exported member`.

```js
// Before
import { loadModule, trpcMiddleware } from "@sentry/core";
import type { BrowserClientReplayOptions } from "@sentry/core";

// After
import { loadModule, trpcMiddleware } from "@sentry/core/server";
import type { BrowserClientReplayOptions } from "@sentry/core/browser";
```

* `sendDefaultPii` was removed. Use [`dataCollection`](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#data-collection) instead.
* `Scope.clear()` was removed. To reset scope state, re-initialize the SDK or run your code in a fresh scope with `withScope` or `withIsolationScope`.
* The `disableInstrumentationWarnings` option and the `MissingInstrumentationContext` type were removed. With channel-based instrumentation, the SDK can no longer detect that a framework was imported before `Sentry.init()`.
* `createSpanEnvelope` and the `SpanEnvelope` and `SpanItem` types were removed. Standalone spans are gone: spans are sent on their transaction, or as streamed spans.
* The positional `spanOrigin` argument of `instrumentFetchRequest` was removed. Pass an options object as the last argument instead.
* The internal `addAutoIpAddressToUser` export was removed.

### [AI Integrations](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#ai-integrations)

* The `enableTruncation` and `streamGenAiSpans` flags were removed. Gen AI spans are always streamed and never truncated now.
* The `addVercelAiProcessors` helper was removed. Add `vercelAIIntegration()` instead.
* The AI instrumentation moved from `@sentry/core` to `@sentry/server-utils`. If you imported a helper such as `instrumentOpenAiClient` or `createLangChainCallbackHandler` directly from `@sentry/core`, import it from your platform SDK (for example `@sentry/node`) or from `@sentry/server-utils`.
* Low-level provider instrumentation internals, integration-name constants, and their types are no longer exported from `@sentry/core`.

### [Profiling](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#profiling)

The legacy per-transaction profiling options were removed. Configure [session-based profiling](https://docs.sentry.io/platforms/javascript/guides/effect/profiling.md) with `profileSessionSampleRate` and a `profileLifecycle` of `'trace'` or `'manual'` instead. The `prune-profiler-binaries` script was removed from `@sentry/profiling-node`.

## [Package Changes](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#package-changes)

* **`@sentry/types` is no longer published.** Import all types from `@sentry/core`. The package has only re-exported from `@sentry/core` since v8.
* **`@sentry/node-core` was merged back into `@sentry/node`.** With the reduced OpenTelemetry footprint, it no longer serves a purpose. Import everything from `@sentry/node`.
* **`@sentry/tanstackstart` was removed.** Use `@sentry/tanstackstart-react`.
* **Metrics moved out of the base CDN bundle.** They ship only in the `*.logs.metrics` bundles now. On the other bundles, `Sentry.metrics.*` is a no-op that warns in debug builds.

## [Renames](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#renames)

These integrations and options kept their behavior, but changed their name.

### [The `InboundFilters` Integration Is Now `EventFilters`](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#the-inboundfilters-integration-is-now-eventfilters)

The `inboundFiltersIntegration` export was removed, and the integration reports itself as `EventFilters`. Update references by name, for example in `client.getIntegrationByName()`:

```js
// Before
Sentry.init({
  integrations: (integrations) =>
    integrations.filter((integration) => integration.name !== "InboundFilters"),
});

// After
Sentry.init({
  integrations: (integrations) =>
    integrations.filter((integration) => integration.name !== "EventFilters"),
});
```

## [Type Changes](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#type-changes)

* Several public types that used `any` now use `unknown`, including `StackFrame`, `SamplingContext`, `SentryError`, and `User`. You may need to narrow types explicitly.
* Attribute typing and serialization were unified across the SDK.
* The `attributes` field of the `SamplingContext` passed to `tracesSampler` is required now. The SDK always provides it, so this only affects code that narrows or builds `SamplingContext` objects by hand.
* The `attributes` field of `ScopeData` is required now. This only affects code that constructs `ScopeData` objects manually: add `attributes: {}` there.
* The `endTimestamp` property was removed from `SentrySpanArguments`. Call `span.end(timestamp)` instead.
* `BrowserOptions` supports the `TransportOptions` generic now.

## [No Version Support Timeline](https://docs.sentry.io/platforms/javascript/guides/effect/migration/v10-to-v11.md#no-version-support-timeline)

Version support timelines are stressful for everybody using the SDK, so we won't be defining one. Instead, we will be applying bug fixes and features to older versions as long as there is demand.

Additionally, we hold ourselves accountable to any security issues, meaning that if any vulnerabilities are found, we will in almost all cases backport them.

It's decided on a case-by-case basis what gets backported. If you need a fix or feature in a previous version of the SDK, please reach out via a [GitHub issue](https://github.com/getsentry/sentry-javascript/issues).