Migrate from 9.x to 10.x

Version 10 of the Sentry JavaScript SDK primarily focuses on upgrading underlying OpenTelemetry dependencies to v2 with minimal breaking changes.

Version 10 of the SDK is compatible with Sentry self-hosted versions 24.4.2 or higher (unchanged from v9). Lower versions may continue to work, but may not support all features.

Version Support Changes:

Version 10 of the Sentry SDK has new compatibility ranges for runtimes and frameworks.

Node.js

All OpenTelemetry dependencies have been bumped to 2.x.x / 0.20x.x respectively, and all OpenTelemetry instrumentations have been upgraded to their latest version.

If you cannot run with OpenTelemetry v2 versions, consider either staying on Version 9 of our SDKs or using @sentry/node-core instead, which ships with widened OpenTelemetry peer dependencies.

AWS Lambda Layer Changes

A new AWS Lambda Layer for version 10 will be published as SentryNodeServerlessSDKv10.

Updates and fixes for version 9 will be published as SentryNodeServerlessSDKv9.

Removed FID Web Vital reporting

The SDKs no longer report the First Input Delay (FID) web vital.

This was done because FID has been replaced by Interaction to Next Paint (INP) and is therefore no longer relevant for assessing and tracking a website's performance. For reference, FID has long been deprecated by Google's official web-vitals library and was eventually removed in version 5.0.0. Sentry now follows Google's lead by also removing it.

The removal entails no breaking API changes. However, in rare cases, you might need to adjust some of your Sentry SDK and product setup:

• Remove any logic in beforeSend or other filtering/event processing logic that depends on FID or replace it with INP logic.
• If you set up Sentry Alerts that depend on FID, be aware that these could trigger once you upgrade the SDK, due to a lack of new values. To replace them, adjust your alerts (or dashboards) to use INP.

Removed _experiments.autoFlushOnFeedback for Session Replays

The _experiments.autoFlushOnFeedback option was removed and is now the default behavior.

Update: User IP Address collection gated by sendDefaultPii

Version 10.4.0 introduced a change that should have ideally been introduced with 10.0.0 of the SDK. Originally destined for version 9.0.0, but having not the desired effect until v10, SDKs will now control IP address inference of user IP addresses depending on the value of the top level sendDefaultPii init option.

• If sendDefaultPii is true, Sentry will infer the IP address of users' devices to events (errors, traces, replays, etc) in all browser-based SDKs.
• If sendDefaultPii is false or not set, Sentry will not infer or collect IP address data.

Given that this was already advertised behaviour since v9, we classify the change as a fix, though we recognize the potential impact of it.

If you want to continue receiving user IP addresses, set sendDefaultPii: true in your Sentry.init config:

Sentry.init({
  // ...
  sendDefaultPii: true,
});

We apologize for any inconvenience caused.

Removed APIs

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

• BaseClient was removed, use Client as a direct replacement.
• hasTracingEnabled was removed, use hasSpansEnabled as a direct replacement.
• The internal logger and type Logger exports in @sentry/core were removed, use debug and type SentryDebugLogger instead. This does not affect the logger export used for Sentry Logging
• The _experiments.enableLogs and _experiments.beforeSendLog options were removed, use the top-level enableLogs and beforeSendLog options instead.

// before
Sentry.init({
  _experiments: {
    enableLogs: true,
    beforeSendLog: (log) => {
      return log;
    },
  },
});

// after
Sentry.init({
  enableLogs: true,
  beforeSendLog: (log) => {
    return log;
  },
});

Version Support Timeline

Version support timelines can be 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 for any security issues, meaning that if any vulnerabilities are found, we will, in almost all cases, backport them.

Note, that backporting decisions are made on a case-by-case basis. If you need a fix or feature in a previous version of the SDK, please reach out via a GitHub Issue.