JS SDK v8 Deprecations List

[AbhiPrasad]

This PR contains the list of deprecated items that will be removed in the upcoming v8 major version of the SDK.

Confirmed Removals

Preview Give feedback

1. The utility functions and types in the Node SDK's exported Handlers object have been moved out of Handlers to the top level of the SDK exports, and parseRequest has been renamed addRequestDataToEvent. See ref(node): Move request-data-extraction functions to@sentry/utils #5257 and search for TODO (v8 / #5257) in the codebase.
2. With the introduction of the tracePropagationTargets option we can remove tracingOrigins. (TODO link PRs and Issues - @lforst)
3. Remove @sentry/hub package [v8] Remove @sentry/hub package #5665
4. Prepare for Svelte 5 support #10318
   4 of 4
   Type: Improvement +1
   
5. Remove componentTrackingPreprocessor export from Svelte SDK (Svelte Component Tracking doesn't pick up components without a <script> tag #5923)
6. Remove guards to calls of optional methods on the BaseClient once we made these methods required (SDK lifecycle hooks #7262, addIntegration, getSdkMetadata, on, emit)
7. Remove withSentry in favor of withSentryAPI
8. Remove SyncPromise
9. Remove wrap function (Deprecate or Change type of exported wrap function #8897)
10. Remove @sentry/tracing package [v8] Remove @sentry/tracing package #8796
11. Remove offline integration ref(integrations): Remove offline integration #9456
12. Remove static id property from integrations because static fields could have side effects and are therefore not tree-shakable. (@lforst for more info)

Up for discussion

Preview Give feedback

1. Stop supporting Angular 10 (and 11) to enable native Ivy support (i.e. get rid of currently necessary ngcc coversion). feat(angular): Add Angular 14 support #5253 (comment)
2. Drop support for Node 8/10/12
3. [v9] Remove Ambiguous Vue component tracking options #5907
   Feature: Spans Meta: Breaking Package: vue Type: Improvement +4
4. Remove Gatsby Plugin configuration in favour of only using sentry.config.ts/sentry.config.js
5. ClientOptions::initialScope (see Add instructions for adding initial scope when using BrowserClient sentry-docs#5345 (comment))
6. Remove TryCatch integration from exported defaultIntegration of Angular(-Ivy) SDKs or write angular-specific tryCatch and refactor global tryCatch (Angular - errors are reported multiple times #2744, [@sentry/angular - @sentry/browser] Setting context data (tags, extra or context) for errors/exceptions is not working in an async context #5417, fix(angular): Filter out TryCatch integration by default #8367 (review))
7. AWS SDK v3 Support (v2 deprecation) #8575
   Meta: Breaking Package: serverless +2
8. Remove deprecated Severity enum
9. Remove need for DSN if using tunnel dsn not optional with tunnel #9377
10. Reconsider all calls to hasTracingEnabled() because of TwP (we use hasTracingEnabled() to detect if performance should be turned on, making the name very misleading because it refers to tracing and not performance, even though that's what it is about)
11. Remove docs for the Node.js AWS Lambda Docker Image (Sentry AWS Lambda Container Image (Node) generates setPropagationContext is not a function with serverless package #9762) https://docs.sentry.io/platforms/node/guides/aws-lambda/container-image/

[csvn]

From: #5253 (comment)

When we first released @sentry/angular, we started with NG10 which means that we want to support this version as long as reasonably possible

In any case, dropping support for an Angular version is a breaking change which means that we'll only be able to do this with the next major release of the SDK.

I've seen many packages have a notice at the top of the README.md, showing what version to install when used with older versions of another library. Maybe it makes sense to have 7.x.x support Angular v10+, and 8.x.x supports only Ivy releases and onwards? Important features could still be backported to between the different versions.

It would be nice to be able to get rid of ngcc conversion and warnings during the build. 😇

[lforst]

Just crossed my mind: We can think about removing the static id fields from integrations since we found it has tree shaking drawbacks. Adding this to "Up for discussion".

[AbhiPrasad]

I think this is pretty much covered by #9508, so closing!