Noticed we forgot to set this.

…12203)

The action sets up node 18 currently anyway, this doesn't seem to have
any effect.

…ateElement` (#12204)

Closes #12200

From my personal testing everything works with with React 19, so we can
bump the peer dep.

For the new error APIs, there is
#12147, but that PR
is draft while we get feedback from the React team.

…t docs (#12209)

#12210)

resolves #12176

Given the test apps are having issues, disable these tests for now.

…import (#12185)

Based on the great feedback in
#12191, this
does some small adjustments to ensure that you actually can use the Node
SDK properly with a custom OTEL setup:

## 1. Ensure we do not run `validateOpenTelemetrySetup()` when
`skipOpenTelemetrySetup` is configured.

Today, this is impossible to fix because you need a client to create the
sampler, and you need the sampler to satisfy the validation, but the
validation runs in `init()`. So either you call init() before doing your
manual setup, which means you get the warning, or you do the manual
setup first, but then you can't actually add the sampler, and still get
the warning.

This change means that users that configure `skipOpenTelemetrySetup` can
manually call `Sentry.validateOpenTelemetrySetup()` if they want to get
the validation, else there will be no validation automtically.

## 2. Export `SentryContextManager` from `@sentry/node`

This is easier to use than to use the primitive
`wrapContextManagerClass` from `@sentry/opentelemetry`.

## 3. Ensure we always run `setupEventContextTrace`, not tied to
`skipOpenTelemetrySetup`

There is no reason to tie this together, this now just always runs in
`init()` - it's just an event processor!

This allows to pass a custom scope to `Sentry.captureFeedback()`, like
this:

```js
Sentry.captureFeedback({message : 'test' }, {}, scope);
```

This should fix the use case from
#11072 (comment)

Add a new `Sentry.startNewTrace` function that allows users to
start a trace in isolation of a potentially still active trace. When
this function is called, a new trace will be started on a forked scope
which remains valid throughout the callback lifetime.

This PR adds a new way to initialize `@sentry/node`, which allows to use
the SDK with performance instrumentation even if you cannot (for
whatever reason) call `Sentry.init()` at the very start of your app.

## CJS usage

In CommonJS mode, you can run the SDK like this:

```bash
node --require @sentry/node/preload ./app.js
```

```js
// app.js
const express = require('express');
const Sentry = require('@sentry/node');

const dsn = await getSentryDsn();
Sentry.init({ dsn });

// express is instrumented even though we initialized Sentry late
```

## ESM usage

in ESM mode, you can run the SDK like this:

```bash
node --import @sentry/node/preload ./app.mjs
```

```js
// app.mjs
import express from 'express';
import * as Sentry from '@sentry/node';

const dsn = await getSentryDsn();
Sentry.init({ dsn });

// express is instrumented even though we initialized Sentry late
```

## Configuration options

This script will by default preload all opentelemetry instrumentation.
You can choose to instrument only specific packages like this:

```bash
SENTRY_PRELOAD_INTEGRATIONS="Http,Express,Graphql" --import @sentry/node/preload ./app.mjs
```

You can also enable debug logging for the script via
`SENTRY_DEBUG=true`.

## Manually preloading

It is also possible to manually call `preloadOpenTelemetry()` to achieve
the same thing. For example, in a CJS app you could do the following
thing if you want to initialize late but don't want to use `--require`:

```js
// preload.js
const Sentry = require('@sentry/node');
Sentry.preloadOpenTelemetry();

// app.js
// call this first, before any other requires!
require('./preload.js');
// Then, other stuff
const express = require('express');
const Sentry = require('@sentry/node');

const dsn = await getSentryDsn();
Sentry.init({ dsn });
```

#11979)

Co-authored-by: Francesco Novy <francesco.novy@sentry.io>

We had no entry covering the bundle size of metrics so far.

…mbdas (#12133)

Co-authored-by: Francesco Novy <francesco.novy@sentry.io>

…bda layer bundle (#12232)

FIx one of the two issues that currently cause our lambda
layer to break. When we build the lambda layer bundle we applied
minification via our terser plugin which mangles `_`-prefixed private
variables - like `Module._resolveFilename`. This patch adds the method
to the list of excluded `_`-prefixed symbols.

resolves #11777

Closes #12223

I've added a test that uses `import-in-the-middle` to throw if
`inspector` is imported without enabling the `LocalVariables`
integration so this should not regress in the future.

Note that we don't need to import asynchronously in the worker scripts
since these are not evaluated if the features aren't used.

…ddle` (#12233)

Our lambda layer relies on one bundled Sentry SDK, which caused problems
raised in #12089 and
#12009 (comment).
Specifically, by bundling `import-in-the-middle` code into one file, it
seems like the library's way of declaring its exports conflict, causing
the "ImportInTheMiddle is not a constructor" error to be thrown. While
this should ideally be fixed soon in `import-in-the-middle`, for now
this patch adds a small Rollup plugin to transform `new
ImportInTheMiddle(...)` calls to `new ImportInTheMiddle.default(...)` to
our AWS Lambda Layer bundle config.

Make our check for when we abort and log an error due to
`Sentry.init` being used in a browser extension a bit more fine-gained.
In particular, we now do not abort the SDK initialization if we detect
that the SDK is running in a browser-extension dedicated window (e.g. a
URL starting with `chrome-extension://`).