…17728)

This PR adds the
[no-unnecessary-type-assertion](https://typescript-eslint.io/rules/no-unnecessary-type-assertion/)
eslint rule.

This rule captures unneeded type assertions/conversions. E.g. the
following code will be raised:

```js
const thing = { name: 'string' };

// no need for !, this def. exists
thing!.name

// no need to cast to string, as this is already the type
thing.name as string; 
```

note that this also expects you to use generics where possible instead
of casting types, which is nicer anyhow (e.g.
`getIntegrationByName<IntegrationType>(..)` vs `getIntegrationByName(..)
as IntegrationType`).

[Gitflow] Merge master into develop

We already officially only support es2020, so we may as well also use
this as lib & target everywhere.

…the browser (#17714)

This PR adds a long-requested feature to the browser SDKs (only!):
Making an inactive span active. We do this to enable use cases where
having a span only being active in the callback is not practical (see
#13495 for
examples).

There are a couple of caveats to this feature:
- This on purpose is only exported from the browser SDKs. We cannot
support this in Node, due to OTel not allowing for a similar hack.
Frankly, it also makes no sense in Node-based SDKs.
- Calling `setActiveSpanInBrowser ` on a nested child span, will make
that child span the active span as long as it is active. However, due to
`parentSpanIsAlwaysRootSpan` defaulting to `true` any child span of the
active child span, will still be parented to the root span. By setting
`parentSpanIsAlwaysRootSpan: false`, the span hierarchy is respected and
child spans are correctly parented to the active span. Note that this
cannot be guaranteed to work perfectly, due to missing async context in
the browser. See tests for the `parentSpanIsAlwaysRootSpan` behaviour.
- A span once set active, cannot be set as inactive again. It will
remain active until it is ended or until another span is set active. In
the latter case, once that span ends, the initial span will be set as
active again until it ends. This is reflected in the types where we by
design only allow `Span` to be passed to `setActiveSpanInBrowser `.

Technically, `setActiveSpanInBrowser` uses `_setSpanForScope` which I
decided to re-export from core as `_INTERNAL_setSpanForScope`, similarly
to how we do it with logs APIs.

### Usage

This example shows one of the most frequent use cases where having an
active, callback-unbound span is useful:

```js
function instrumentMyRouter() {
  let routeSpan;
  
  on('routeStart', (from, to) => {
    routeSpan = Sentry.startInactiveSpan({name: `/${from} -> /${to}`});
    Sentry. setActiveSpanInBrowser(rootSpan);
  });


  // any span started in the meantime (e.g. fetch requests) will be
  // automatically parented to `routeSpan`
  
  on('routeEnd', () => {
    // automatically removes the span from the scope
    routeSpan.end();
  })
}
```

closes #13495

## Summary

This PR enhances the Hono integration by adding comprehensive handler
instrumentation, error handling capabilities, and thorough test
coverage. The changes build upon the basic Hono integration to provide a
complete tracing and error monitoring solution.


## New Features

- Handler Instrumentation: Added instrumentation for Hono handlers and
middleware, providing detailed tracing capabilities
- Error Handler: Implemented setupHonoErrorHandler() function to capture
and report errors to Sentry with configurable error filtering
- Public API: Added Hono integration to the main package exports, making
it available as @sentry/node
- Tracing Module: Included Hono integration in the tracing integrations
index

## Bug Fixes

- CJS Compatibility: Fixed an issue where applying patches failed in
CommonJS environments
- Type Corrections: Fixed incorrect MiddlewareHandler type definition to
ensure proper TypeScript support

## Implementation Details

- Instrumentation: Created HonoInstrumentation class that wraps Hono
middleware handlers via class extension instead of function replacement
for better compatibility
- Type Definitions: Added comprehensive TypeScript type definitions
vendored from Hono's official types
- Constants: Defined Hono-specific attribute names for OpenTelemetry
integration
- CJS Compatibility: Fixed patching issues in CommonJS environments

## Testing

- Integration Tests: Added comprehensive test suite covering:
  - ESM and CJS compatibility
  - Multiple HTTP methods (GET, POST, PUT, DELETE, PATCH)
  - Various route patterns (sync/async, different paths)
  - Middleware and handler instrumentation verification
  - Error handling scenarios
  - Span attribute validation

## Related Issue

close #15260

This PR adds the external contributor to the CHANGELOG.md file, so that
they are credited for their contribution. See #17428

Co-authored-by: s1gr1d <[email protected]>

…yer (#17684)

Enables the Lambda extension by default when using the Lambda layer

---------

Co-authored-by: Francesco Gringl-Novy <[email protected]>

… values (#17751)

This patch
- drops any `http.request.*` timing attributes where the original value was `undefined`
- sends `0` for any `http.request.*` timing attribte values that were originally `0` (i.e. no
longer converts them to the `timeOrigin` absolute timestamp)

---------

Co-authored-by: Abhijeet Prasad <[email protected]>

Rewording this as it is not actually correct, this is not
auto-instrumented but needs to be done manually - see
#17723

…#17743)

This adds a `honoIntegration` that exposes a `shouldHandleError`
function that lets users define a custom handling of capturing errors.
By default, we capture exceptions with `error.status >= 500 ||
error.status <= 299`.

It's possible to modify this behavior like this:

```js
integrations: [
  honoIntegration({
    shouldHandleError: (err) => true; // always capture exceptions in onError
  })
]
```

**Up for discussion**: The function name is the same like in
express/fastify to keep it consistent. But I was also thinking about
other names like `shouldHandleInOnError` or `shouldCaptureOnError` 🤔
Because it's specifically about the `onError` function. Let me know what
you think.

closes #17717

meta(changelog): Update changelog for 10.15.0