feat(v8): Update node docs for v8

docs/organization/integrations/cloud-monitoring/aws-lambda/index.mdx

@@ -123,7 +123,7 @@ provider:
   environment:
     SENTRY_TRACES_SAMPLE_RATE: "1.0"
     SENTRY_DSN: "<SENTRY_DSN>"
-    NODE_OPTIONS: "-r @sentry/serverless/dist/awslambda-auto"
+    NODE_OPTIONS: "-r @sentry/aws-serverless/dist/awslambda-auto"
 
 custom:
   layers:

docs/organization/integrations/session-replay/atlas/index.mdx

@@ -43,7 +43,7 @@ apiAxios.interceptors.request.use((config) => {
 You can send this to the Sentry via your Client SDK:
 
 ```javascript
-Sentry.addGlobalEventProcessor((event) => {
+Sentry.addEventProcessor((event) => {
   event.tags = {
     ...(event.tags || {}),
     ["atlasSupport.sessionId"]: window.Atlas?.recording?.getSessionId(),

docs/platforms/javascript/common/best-practices/multiple-sentry-instances.mdx

@@ -77,7 +77,7 @@ function happyIntegration() {
   return {
     name: 'Happy',
     setupOnce() {
-      Sentry.addGlobalEventProcessor((event) => {
+      Sentry.addEventProcessor((event) => {
         const self = Sentry.getClient().getIntegration(HappyIntegration);
         // Run the integration ONLY when it was installed on the current Hub
         if (self) {

docs/platforms/javascript/common/configuration/async-context.mdx

@@ -10,32 +10,42 @@ supported:
   - javascript.express
   - javascript.gcp-functions
   - javascript.koa
+  - javascript.fastify
 ---
 
-You can use the `runWithAsyncContext` method to isolate Sentry scope and breadcrumbs to a single request if you are using SDK v7.48.0 or higher. This is useful if you are finding that breadcrumbs and scope are leaking across requests.
+By default, the Sentry SDK will automatically isolate each request's scope and breadcrumbs. This means that any breadcrumbs or tags added will be isolated to the request. This is useful if you are finding that breadcrumbs and scope are leaking across requests. Take the following example:
 
-```javascript
+```js
 const Sentry = require("@sentry/node");
 
-function requestHandlerMiddleware(req, res, next) {
-  // Any breadcrumbs or tags added will be isolated to the request
-  return Sentry.runWithAsyncContext(() => {
-    return next(req, res);
+app.get("/my-route", function () {
+  Sentry.addBreadcrumb({
+    message: "This breadcrumb should only be attached to this request",
   });
-}
+  // do something
+});
+
+app.get("/my-route-2", function () {
+  Sentry.addBreadcrumb({
+    message: "This breadcrumb should only be attached to this request",
+  });
+  // do something
+});
 ```
 
-Under the hood, the SDK uses Node's [AsyncLocalStorage API](https://nodejs.org/api/async_context.html#class-asynclocalstorage) to perform the isolation.
+Each request will have its own breadcrumbs, and they will not be shared between requests.
 
-On lower SDK versions you'll have to use [domains](https://nodejs.org/api/domain.html) to isolate Sentry scope and breadcrumbs to a single request.
+If you want to manually isolate some code, such as for a background job, you can use the `withIsolationScope` method. This will ensure that any breadcrumbs or tags added will be isolated inside of the provided callback:
 
-```javascript
-const domain = require("domain");
+```js
+const Sentry = require("@sentry/node");
 
-function myRequestHandler(req, res, next) {
-  const localDomain = domain.create();
-  return localDomain.bind(() => {
-    return next(req, res);
-  })();
+async function backgroundJob() {
+  return await Sentry.withIsolationScope(async () => {
+    // Everything inside of this will be isolated
+    await doSomething();
+  });
 }
 ```
+
+Under the hood, the SDK uses Node's [AsyncLocalStorage API](https://nodejs.org/api/async_context.html#class-asynclocalstorage) to perform the isolation.

docs/platforms/javascript/common/configuration/integrations/http.mdx

@@ -27,14 +27,8 @@ This integration is enabled by default. If you'd like to modify your default int
 
 The `httpIntegration` does two things:
 
-<PlatformSection notSupported={["javascript.fastify"]}>
-1. It captures breadcrumbs for HTTP requests.
-2. When the [`tracing`](#tracing) option is enabled, it captures spans for outgoing HTTP requests.
-</PlatformSection>
-<PlatformSection supported={["javascript.fastify"]}>
 1. It captures breadcrumbs for HTTP requests.
 2. It captures spans for outgoing HTTP requests.
-</PlatformSection>
 
 ## Options
 
@@ -44,15 +38,6 @@ _Type: `boolean`_
 
 If set to false, no breadcrumbs will be captured.
 
-<PlatformSection notSupported={["javascript.fastify"]}>
-### `tracing`
-
-_Type: `boolean`_
-
-If set to true, spans will be captured for outgoing HTTP requests.
-</PlatformSection>
-
-<PlatformSection supported={["javascript.fastify"]}>
 ### `ignoreOutgoingRequests`
 
 _Type: `(url: string) => boolean`_
@@ -64,4 +49,3 @@ Allows you to define a method to filter out outgoing requests based on the URL.
 _Type: `(url: string) => boolean`_
 
 Allows you to define a method to filter out incoming requests based on the URL. If the method returns `true`, the request will be ignored.
-</PlatformSection>

docs/platforms/javascript/common/configuration/integrations/nodefetch.mdx

@@ -26,10 +26,10 @@ _Import name: `Sentry.nativeNodeFetchIntegration`_
 This integration is enabled by default starting in v8.0.0. If you'd like to modify your default integrations, read [this](./../#modifying-default-integrations).
 
 The `nativeNodeFetchIntegration` does two things:
+
 1. It captures spans for fetch requests.
 2. It captures breadcrumbs for fetch requests.
 
-
 ## Options
 
 ### `breadcrumbs`
@@ -38,18 +38,8 @@ _Type: `boolean`_
 
 If set to false, no breadcrumbs will be captured.
 
-<PlatformSection notSupported={["javascript.fastify"]}>
-### `ignoreOutgoingRequests`
-
-_Type: `(url: string) => boolean`_
-
-Allows you to define a method to filter out outgoing requests based on the URL. If the method returns `true`, the request will be ignored.
-</PlatformSection>
-
-<PlatformSection supported={["javascript.fastify"]}>
 ### `ignoreOutgoingRequests`
 
 _Type: `(url: string) => boolean`_
 
 Allows you to define a method to filter out outgoing requests based on the URL. If the method returns `true`, the request will be ignored.
-</PlatformSection>

docs/platforms/javascript/common/distributed-tracing/dealing-with-cors-issues/index.mdx

@@ -1,6 +1,16 @@
 ---
 title: Dealing with CORS Issues
 sidebar_order: 80
+notSupported:
+  - javascript.cordova
+  - javascript.node
+  - javascript.aws-lambda
+  - javascript.azure-functions
+  - javascript.connect
+  - javascript.express
+  - javascript.gcp-functions
+  - javascript.koa
+  - javascript.fastify
 ---
 
 If your frontend and backend are hosted on different domains (for example, your frontend is on `https://example.com` and your backend is on `https://api.example.com`), and the frontend does XHR/fetch requests to your backend, you'll need to configure your backend [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) headers to ensure requests aren't blocked.

docs/platforms/javascript/common/enriching-events/event-processors/index.mdx

@@ -10,7 +10,7 @@ You can enrich events with additional data by adding your own event processors,
   get the final version of the event right before it's sent, hence the name). Event
   processors added with either of the methods below run in an undetermined order,
   which means changes to the event may still be made after the event processor runs.
-- While <PlatformIdentifier name="before-send" />, <PlatformIdentifier name="before-send-transaction" />, and processors added with <PlatformIdentifier name="Sentry.add-global-event-processor" /> run globally, regardless of scope, processors added with <PlatformIdentifier name="scope.add-event-processor" /> only run on events captured while that scope is active.
+- While <PlatformIdentifier name="before-send" />, <PlatformIdentifier name="before-send-transaction" />, and processors added with `Sentry.addEventProcessor` run globally, regardless of scope, processors added with <PlatformIdentifier name="scope.add-event-processor" /> only run on events captured while that scope is active.
 
 Like <PlatformIdentifier name="before-send" /> and <PlatformIdentifier name="before-send-transaction" />, event processors are passed two arguments, the event itself and <PlatformLink to="/configuration/filtering/#using-hints">a `hint` object</PlatformLink> containing extra metadata.
 

docs/platforms/javascript/common/install/commonjs.mdx

@@ -0,0 +1,16 @@
+---
+title: CommonJS (CJS)
+sidebar_order: 9
+description: "Learn about running Sentry in an CJS application."
+supported:
+  - javascript.node
+  - javascript.connect
+  - javascript.express
+  - javascript.fastify
+  - javascript.koa
+---
+
+Most node applications today are either written in CommonJS (CJS), or compiled to CJS before running them.
+CommonJS uses `require()` to load modules. Our recommended installation method when using CommonJS is to require the `instrument.js` file at the top of your application.
+
+<PlatformContent includePath="getting-started-use" />

docs/platforms/javascript/common/install/esm.mdx

@@ -0,0 +1,29 @@
+---
+title: ESM (MJS)
+sidebar_order: 10
+description: "Learn about running Sentry in an ESM application."
+supported:
+  - javascript.node
+  - javascript.connect
+  - javascript.express
+  - javascript.fastify
+  - javascript.koa
+---
+
+When running your application in ESM mode, you can't use `require()` to load modules. Instead, you have to use the  `--import` command line options to load a module before the application starts:
+
+Adjust the Node.js call for your application to use the [--import](https://nodejs.org/api/cli.html#--importmodule) parameter and point it at `instrument.js`, which contains your `Sentry.init()` code:
+
+```bash
+# Note: This is only available for Node v18.19.0 onwards.
+node --import ./instrument.mjs app.mjs
+```
+
+We do not support ESM in Node versions before 18.19.0.
+
+## When to use this
+
+Most node applications today are either written in CommonJS (CJS), or compiled to CJS before running them.
+CommonJS uses `require()` to load modules. Our recommended installation method when using CommonJS is to require the `instrument.js` file at the top of your application. However, if your application is run in ESM mode, this will not work. In this case, you can follow the [ESM docs](./esm).
+
+Note that even if your application is written in ESM (using `import`), it may still be _run_ in CJS. For example, almost all applications written in TypeScript are compiled to CJS before running them. In this case, you should follow the CommonJS instructions.

docs/platforms/javascript/common/install/index.mdx

@@ -19,18 +19,40 @@ notSupported:
   - javascript.remix
   - javascript.svelte
   - javascript.sveltekit
-  - javascript.node
   - javascript.aws-lambda
   - javascript.azure-functions
-  - javascript.connect
-  - javascript.express
-  - javascript.fastify
   - javascript.gcp-functions
-  - javascript.koa
 ---
 
 <PageGrid />
 
+<PlatformCategorySection supported={['server']}>
+
+## How To Decide Which Installation Method To Use
+
+Most node applications today are either written in CommonJS (CJS), or compiled to CJS before running them.
+CommonJS uses `require()` to load modules. Our recommended installation method when using CommonJS is to require the `instrument.js` file at the top of your application. However, if your application is run in ESM mode, this will not work. In this case, you can follow the [ESM docs](./esm).
+
+Note that even if your application is written in ESM (using `import`), it may still be _run_ in CJS. In this case, you should follow the [CommonJS instructions](./commonjs).
+
+### My application is in TypeScript
+
+If you're using TypeScript, your application is likely compiled to CommonJS before running it. In this case, you should follow the [CommonJS instructions](./commonjs).
+
+### My application uses `require`
+
+If you are using `require()` in your application, you should follow the [CommonJS instructions](./commonjs).
+
+### My application uses `import`
+
+If you are using `import` in your application, your installation method depends on how your application is _run_. If you compile your application (e.g. into a `/dist` folder or similar) before running this, you need to check how the compiled code looks like. Is the compiled code using `require`? Then you should follow the [CommonJS instructions](./commonjs). If the compiled code is using `import`, you should follow the [ESM instructions](./esm).
+
+If you do not compile your code, you'll need to follow the [ESM instructions](./esm).
+
+</PlatformCategorySection>
+
+<PlatformCategorySection supported={['browser']}>
+
 ## How To Decide Which Installation Method To Use
 
 Depending on the concrete needs of your application, you may wonder which installation method you should use.
@@ -63,3 +85,5 @@ In these scenarios, using the npm package is the better choice:
 - **Full public API**: The Loader Script only exposes a subset of public APIs (for example, `Sentry.captureException()`, ...). If you need a lot of custom functionality, you're likely better off with the npm package.
 
 - **Full control over the SDK version**: If you need full control over the SDK version, you'll need to install the SDK via npm.
+
+</PlatformCategorySection>

docs/platforms/javascript/common/install/loader.mdx

@@ -2,6 +2,31 @@
 title: Loader Script
 sidebar_order: 10
 description: "Learn about the Sentry JavaScript Loader Script"
+notSupported:
+  - javascript.angular
+  - javascript.astro
+  - javascript.bun
+  - javascript.deno
+  - javascript.capacitor
+  - javascript.cordova
+  - javascript.electron
+  - javascript.ember
+  - javascript.gatsby
+  - javascript.nextjs
+  - javascript.react
+  - javascript.vue
+  - javascript.wasm
+  - javascript.remix
+  - javascript.svelte
+  - javascript.sveltekit
+  - javascript.node
+  - javascript.aws-lambda
+  - javascript.azure-functions
+  - javascript.connect
+  - javascript.express
+  - javascript.fastify
+  - javascript.gcp-functions
+  - javascript.koa
 ---
 
 The Loader Script is the easiest way to initialize the Sentry SDK. The Loader Script also automatically keeps your Sentry SDK up to date and offers configuration for different Sentry features.
@@ -92,7 +117,7 @@ You can configure the release by adding the following to your page:
 
 ### Custom Configuration
 
-The loader script always includes a call to `Sentry.init` with a default configuration, including your DSN. If you want to <PlatformLink to="/configuration/options/">configure your SDK</PlatformLink> beyond that, you can configure a custom init call by defining a `window.sentryOnLoad` function. Whatever is defined inside of this function will _always_ be called first, before any other SDK method is called. 
+The loader script always includes a call to `Sentry.init` with a default configuration, including your DSN. If you want to <PlatformLink to="/configuration/options/">configure your SDK</PlatformLink> beyond that, you can configure a custom init call by defining a `window.sentryOnLoad` function. Whatever is defined inside of this function will _always_ be called first, before any other SDK method is called.
 
 **Be sure to define this function _before_ you add the loader script, to ensure it can be called at the right time:**
 

docs/platforms/javascript/common/install/npm.mdx

@@ -2,6 +2,31 @@
 title: NPM
 sidebar_order: 0
 description: "Learn about installing with NPM."
+notSupported:
+  - javascript.angular
+  - javascript.astro
+  - javascript.bun
+  - javascript.deno
+  - javascript.capacitor
+  - javascript.cordova
+  - javascript.electron
+  - javascript.ember
+  - javascript.gatsby
+  - javascript.nextjs
+  - javascript.react
+  - javascript.vue
+  - javascript.wasm
+  - javascript.remix
+  - javascript.svelte
+  - javascript.sveltekit
+  - javascript.node
+  - javascript.aws-lambda
+  - javascript.azure-functions
+  - javascript.connect
+  - javascript.express
+  - javascript.fastify
+  - javascript.gcp-functions
+  - javascript.koa
 ---
 
 <PlatformContent includePath="getting-started-install" />