docs(javascript): Add v10 to v11 migration guide - #19217
Conversation
Fill in the one-page migration guide for the JavaScript SDK v11, which was a placeholder before. The content follows the SDK's MIGRATION.md. Long tables and optional details are in expandable sections, and framework and runtime specific changes are filtered per guide, so each platform page only shows what applies to it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
| ```js | ||
| // Before | ||
| Sentry.init({ skipOpenTelemetrySetup: true }); | ||
|
|
||
| // After | ||
| Sentry.init({ enableOpenTelemetrySetup: false }); | ||
| ``` |
There was a problem hiding this comment.
Bug: The migration example for skipOpenTelemetrySetup is misleading. It suggests a simple rename to enableOpenTelemetrySetup, which breaks custom OpenTelemetry setups due to a change in semantics.
Severity: HIGH
Suggested Fix
Remove the simple rename example or clarify it. The guide should explicitly state that users with custom OTel setups must follow the more detailed instructions involving openTelemetryIntegration() and point them to that section. The simple example is only valid for a different, less common use case.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: docs/platforms/javascript/common/migration/v10-to-v11/index.mdx#L562-L568
Potential issue: The migration guide incorrectly suggests that `Sentry.init({
skipOpenTelemetrySetup: true })` in v10 is equivalent to `Sentry.init({
enableOpenTelemetrySetup: false })` in v11. This is misleading because the v10 option
was used to disable Sentry's OTel setup to allow for a custom one. Following the guide's
simple rename will cause a user's custom OpenTelemetry setup to break silently, as it
will no longer be wired up. The correct migration for this use case involves using the
`openTelemetryIntegration()` as described in a different section of the document.
There was a problem hiding this comment.
IMHO the example is weird because it infers you should set this to false to replace the previous skipOpenTelemetrySetup which is not what you need to do. I think this example can probably be omitted, a single example does not explain anything here 😅
| | React | 17 | | ||
| | Astro | 4 | | ||
| | React Router (framework mode) | 7.15 | | ||
| | Remix (`@remix-run/node`) | 2 | |
There was a problem hiding this comment.
We already dropped remix v1 in a prev major, this line can be removed
|
|
||
| ## Next.js Changes | ||
|
|
||
| The build-time configuration moved and dropped its long-deprecated options. |
|
|
||
| ### Removed Build Options | ||
|
|
||
| The long-deprecated top-level options of `withSentryConfig` were removed. Most of them moved under `webpack` in v10: |
There was a problem hiding this comment.
Same here, would get rid of long-deprecated
|
|
||
| ### Other Next.js Changes | ||
|
|
||
| - Tracing was removed from the generated Pages Router API handler, Edge API handler, and Middleware wrapper templates. Route handlers and middleware are still instrumented automatically, so no action is required for most setups. |
There was a problem hiding this comment.
I think we can omit this line here
|
|
||
| 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. | ||
|
|
||
| ### Frameworks and Libraries |
There was a problem hiding this comment.
should we show this section here so generically? What about, instead of this, just showing a line in the respective framework, e.g. in Astro
Raised minimum support of Astro to 4
so you see what actually applies to the current guide?
|
|
||
| <Alert level="warning"> | ||
|
|
||
| This is a behavior change, not a rename. In v10, an unset `sendDefaultPii` was restrictive. In v11, an unset `dataCollection` collects most categories. |
There was a problem hiding this comment.
I love this message, but would reword it slightly:
| This is a behavior change, not a rename. In v10, an unset `sendDefaultPii` was restrictive. In v11, an unset `dataCollection` collects most categories. | |
| This is a behavior change, not a rename. In v10, an unset `sendDefaultPii` was restrictive. In v11, an unset `dataCollection` collects everything by default. |
plus mentioning somewhere the sensitive information like auth tokens are stripped on a best-effort basis ?
|
|
||
| ### Node.js | ||
|
|
||
| Node.js 18 is no longer supported. The supported versions are **`>=20.19.0`**, **`>=22.12.0`**, and **`>=23.2.0`**. |
There was a problem hiding this comment.
m: Tbh that reads a bit odd. With >=20.19.0 we mean "everything in the 20 range", but >=23.2.0 we mean "everything in the 23 range but also later". So being explicit wouldn't harm either
| Node.js 18 is no longer supported. The supported versions are **`>=20.19.0`**, **`>=22.12.0`**, and **`>=23.2.0`**. | |
| Node.js 18 is no longer supported. The supported versions are **`>=20.19.0 <22.0.0 || >=22.12.0 <23.0.0 || >=23.2.0`**. |
There was a problem hiding this comment.
Technically true but nobody uses these uneven node versions and they go EOL way quicker anyway. I think it's fine as is.
There was a problem hiding this comment.
nobody uses these uneven node versions
famous last words
There was a problem hiding this comment.
Went with naming the gaps plus the raw range, since Node 21 is supported (the SDK falls back to patching node:http below 22.12): "The minimum is 20.19.0, and Node.js 22 needs 22.12 or higher while Node.js 23 needs 23.2 or higher (>=20.19.0 <22.0.0 || >=22.12.0 <23.0.0 || >=23.2.0)". Updated in fca41d4
|
|
||
| ### RPC Trace Propagation Is Explicit | ||
|
|
||
| The `enableRpcTracePropagation` option was removed, and trace context is no longer appended to every RPC call on `env`. List the bindings you call in `rpcTracePropagationBindings` instead: |
There was a problem hiding this comment.
l: Maybe worth to mention that users with our Vite plugin can simply remove enableRpcTracePropagation: true and only allow list external services, or simply link to the option: https://docs.sentry.io/platforms/javascript/guides/cloudflare/tracing/distributed-tracing/#rpc-trace-propagation
Co-authored-by: Jan Peer Stöcklmair <jan.peer@sentry.io>
Co-authored-by: Jan Peer Stöcklmair <jan.peer@sentry.io>
Co-authored-by: Jan Peer Stöcklmair <jan.peer@sentry.io>
Co-authored-by: Jan Peer Stöcklmair <jan.peer@sentry.io>
Two fixes to the v11 migration guide, found while writing the docs version of it (getsentry/sentry-docs#19217): - **Remix version support:** the guide lists `Remix: dropped @remix-run/node v1 (minimum is now v2)`, but that happened in v9 (#14988, shipped in 9.0.0). The peer dependency has been `2.x` ever since, and v11 doesn't change it, so the bullet is removed. - **Next.js build options:** "long-deprecated" overstates it. Those options were deprecated in 10.30.0 (#18343) and removed in v11 (#23221), so the guide now says when it happened. Docs only, no code change. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>


DESCRIBE YOUR PR
Fills in the one-page v10 to v11 migration guide for the JavaScript SDKs, which was a placeholder before. The content follows the SDK's
MIGRATION.md.This is the bottom of a stack. #19076 (interactive guide) goes on top of it and adds the link to the interactive version.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
Select exactly one option. For deadlines, replace
YYYY-MM-DDwith the due date. You can update this information later by editing the PR description.SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: