meta(changelog): Update changelog for 11.5.0

.agents/skills/triage-issue/SKILL.md

@@ -73,11 +73,10 @@ If any of these alternative interpretations apply, capture them in the triage re
 
 ### Step 3: Codebase Research
 
-Search for relevant code using Grep/Glob. Find error messages, function names, and stack trace paths in the local repo.
+Search for relevant code using Grep/Glob. Find error messages, function names, and stack trace paths in the local repo. Bundler plugin code lives in `packages/bundler-plugins`.
 
 Cross-repo searches (only when clearly relevant):
 
-- Bundler issues: `gh api search/code -X GET -f "q=<term>+repo:getsentry/sentry-javascript-bundler-plugins"`
 - Docs issues: `gh api search/code -X GET -f "q=<term>+repo:getsentry/sentry-docs"`
 
 **Shell safety:** Strip shell metacharacters from issue-derived search terms before use in commands.

.agents/skills/triage-issue/assets/triage-report.md

@@ -29,7 +29,6 @@
 
 ### Cross-Repo Findings
 
-- **bundler-plugins:** <findings or "no matches">
 - **sentry-docs:** <findings or "no matches">
 
 ### Recommended Next Steps

.agents/skills/write-tests/SKILL.md

@@ -307,16 +307,31 @@ it.each([
 ### Test isolation
 
 Tests must never depend on execution order or share mutable state. For this codebase, many tests
-need to reset global Sentry state:
+need to reset global Sentry state. Use whatever reset the existing tests in your package use (many
+packages have a `resetSdk()` or `cleanupOtel()` helper). Otherwise, pick one:
 
 ```typescript
-beforeEach(() => {
-  clearGlobalScope();
-  getCurrentScope().clear();
-  getIsolationScope().clear();
-});
+// Unbind the client. Cheap, and enough for most tests that call `init()`.
+getCurrentScope().setClient(undefined);
+
+// Reset the global, isolation, and current scopes, and the client bound to them.
+// `setupOnce` still does not run again, because installed integrations are tracked
+// outside the carrier.
+getMainCarrier().__SENTRY__ = undefined;
+
+// Close and unbind the client. Also flushes, so it is slower.
+await Sentry.close();
 ```
 
+**Reset the client in every test that calls `init()`.** A second `init()` while a client is bound
+prints a "`Sentry.init()` was called more than once" warning. After the next major version, it will
+return the bound client instead of a new one, so a test without a reset gets the previous test's
+client and options. See `docs/repeated-init.md`.
+
+To assert on that warning (or any `consoleSandbox` output), stub `originalConsoleMethods.warn` from
+`@sentry/core`. `consoleSandbox` calls the stored original method, so a spy on `console.warn` misses
+it once the console integration is set up.
+
 ### Grouping
 
 1-2 levels of `describe` is usually enough. Deeper nesting makes tests harder to find and read.
@@ -526,6 +541,7 @@ Before you're done, verify each test against these criteria:
 - [ ] Description reads as a behavior specification (no "should", no "works correctly")
 - [ ] No dependency on other tests' execution or state
 - [ ] Mocks and spies are restored (via `beforeEach`)
+- [ ] Tests that call `init()` reset the bound client between tests
 - [ ] Edge cases covered: empty inputs, boundaries, error paths, null/undefined
 - [ ] Realistic test data (not `"foo"`, `"test"`, `123`)
 - [ ] No try/catch for error testing — `toThrow` / `rejects.toThrow` only

.cursor/BUGBOT.md

@@ -76,6 +76,7 @@ Keep reviews high-signal. Prefer actionable, high-confidence findings over specu
 - Flag usage of the following APIs: `getCurrentScope()`, `getIsolationScope()`, `getClient()` if they are avoidable. Flag it with severity Low and acknowledge from the start that this is more a "is this necessary" check, rather than a rule violation.
   - Reason for flagging: Usage of these APIs is problematic for multi-client setups where either there is no "current" client/scope, or the wrong client might be used. Calling these APIs would create a current scope, thereby misleading any future calls to these APIs.
   - What to do instead: Use an existing reference to the scope or client. For example, this is possible in most `Integration` hooks.
+- Flag hard-coded attribute names and span ops (e.g. `'sentry.origin'`, `'sentry.op'`, `'http.request.method'`, `'db.system.name'`) when `@sentry/conventions` exports a constant for them. Use the constant from `@sentry/conventions/attributes` (e.g. `SENTRY_ORIGIN`, `SENTRY_OP`) or `@sentry/conventions/op` instead. Do not flag values that have no constant in `@sentry/conventions`.
 - Flag unnecessary `span.setAttribute(s)` calls: If data is already available at span start, it must be set via the `attributes` option of `startSpan`, `startSpanManual`, `startInactiveSpan` or `startIdleSpan` calls. This ensures that as much context as possible is available when `tracesSampler` or `ignoreSpans` SDK options are applied. If a `span.setAttribute(s)` call happens at a later time than right after span start and the attribute value can only be computed at that time, do not flag it.
 
 ### Code quality
@@ -92,6 +93,7 @@ Keep reviews high-signal. Prefer actionable, high-confidence findings over specu
 - Flag usage of `expect.objectContaining` and other relaxed assertions, when a test expects something NOT to be included in a payload but there's no respective assertion.
 - Flag usage of conditionals in one test and recommend splitting up the test for the different paths.
 - Flag usage of loops testing multiple scenarios in one test and recommend using `(it)|(test).each` instead.
+- Apply the `@sentry/conventions` constants rule from above to test files too. Test assertions on span attributes and ops must use the constants, not string literals.
 - Flag tests that are likely to introduce flakes. In our case this usually means we wait for some telemetry requests sent from an SDK. Patterns to look out for:
   - Only waiting for a request, after an action is performed. Instead, start waiting, perform action, await request promise.
   - Race conditions when waiting on multiple requests. Ensure that waiting checks are unique enough and don't depend on a hard order when there's a chance that telemetry can be sent in arbitrary order.

.github/dependency-review-config.yml

@@ -30,3 +30,17 @@ allow-ghsas:
   # 0.35.0, which is outside that range. Already present on develop via sharp 0.32.6
   # and 0.34.5, both of which are affected by the same advisory.
   - GHSA-f88m-g3jw-g9cj
+  # axios, pinned exactly to 1.18.1 by nx (dev-only build tooling, not shipped).
+  # Can be removed once nx pins axios >= 1.20.0.
+  - GHSA-542g-h47m-68v8
+  - GHSA-3pq3-5fj3-cg6v
+  - GHSA-x97p-jq2g-jp4f
+  - GHSA-mghh-pgcx-3jjj
+  - GHSA-c29m-xwm3-cm6r
+  - GHSA-r4gj-5m52-g5wh
+  - GHSA-m8m8-qj5v-23w3
+  # brace-expansion, pinned exactly to 5.0.8 by nx (dev-only build tooling, not shipped).
+  # Can be removed once nx pins brace-expansion >= 5.0.11.
+  - GHSA-rgw5-rvv9-x895
+  - GHSA-6j4f-fj2g-mc7p
+  - GHSA-qhr7-859c-m2p7

.github/workflows/build.yml

@@ -1038,6 +1038,8 @@ jobs:
       REACT_APP_E2E_TEST_DSN: 'https://username@domain/123'
       E2E_TEST_SENTRY_ORG_SLUG: 'sentry-javascript-sdks'
       E2E_TEST_SENTRY_PROJECT: 'sentry-javascript-e2e-tests'
+      # The `runtime` of a runtime variant, see dev-packages/e2e-tests/README.md
+      RUNTIME: ${{ matrix.runtime }}
     strategy:
       fail-fast: false
       matrix: ${{ fromJson(needs.job_build.outputs.e2e-matrix) }}
@@ -1056,7 +1058,7 @@ jobs:
       - name: Set up Bun
         if:
           matrix.test-application == 'node-exports-test-app' || contains(matrix.test-application, 'bun') ||
-          contains(matrix.label, 'bun')
+          matrix.runtime == 'bun'
         uses: oven-sh/setup-bun@v2
         with:
           bun-version: '1.3.14'
@@ -1067,7 +1069,7 @@ jobs:
           use-installer: true
           token: ${{ secrets.GITHUB_TOKEN }}
       - name: Set up Deno
-        if: contains(matrix.test-application, 'deno') || contains(matrix.label, 'deno')
+        if: contains(matrix.test-application, 'deno') || matrix.runtime == 'deno'
         uses: denoland/setup-deno@v2.0.5
         with:
           deno-version: ${{ matrix.deno-version || 'v2.8.3' }}
@@ -1177,6 +1179,8 @@ jobs:
       # Used by test apps that deploy a real Cloudflare Worker, e.g. cloudflare-workers-send-to-sentry
       CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
       CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
+      # The `runtime` of a runtime variant, see dev-packages/e2e-tests/README.md
+      RUNTIME: ${{ matrix.runtime }}
     strategy:
       fail-fast: false
       matrix: ${{ fromJson(needs.job_build.outputs.e2e-matrix-optional) }}
@@ -1193,8 +1197,15 @@ jobs:
         uses: actions/setup-node@v7
         with:
           node-version-file: 'dev-packages/e2e-tests/test-applications/${{ matrix.test-application }}/package.json'
+      - name: Set up Bun
+        if:
+          matrix.test-application == 'node-exports-test-app' || contains(matrix.test-application, 'bun') ||
+          matrix.runtime == 'bun'
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: '1.3.14'
       - name: Set up Deno
-        if: matrix.test-application == 'deno'
+        if: contains(matrix.test-application, 'deno') || matrix.runtime == 'deno'
         uses: denoland/setup-deno@v2.0.5
         with:
           deno-version: ${{ matrix.deno-version || 'v2.8.3' }}

AGENTS.md

@@ -76,6 +76,9 @@ Uses **Git Flow** (see `docs/gitflow.md`).
   Runtime packages (`node`, `cloudflare`, ...) re-export from
   `@sentry/server-utils` rather than defining their own.
 
+- `Sentry.init()` follows one rule for repeated calls: the first call wins. See
+  `docs/repeated-init.md` before you add or change an `init()`.
+
 ## Linting & Formatting
 
 - This project uses **Oxlint** and **Oxfmt** — NOT ESLint or Prettier