Stabilize module metadata in MFE docs (#10414)

Author: Luca Forstner

docs/platforms/javascript/common/best-practices/micro-frontends.mdx

@@ -28,7 +28,8 @@ different release cycles, you may want to identify these or route events to spec
 Below we offer two approaches.
 
 <Note>
-In all cases `Sentry.init()` must never be called more than once, doing so will result in undefined behavior.
+  In all cases `Sentry.init()` must never be called more than once, doing so
+  will result in undefined behavior.
 </Note>
 
 ## Automatically Route Errors to Different Projects Depending on Module
@@ -38,20 +39,19 @@ events to different Sentry projects based on the module where the error
 occurred.
 
 <Note>
-<ul>
-<li>
-Requires version `2.5.0` or higher of `@sentry/webpack-plugin` or version
-`2.7.0` or higher of `@sentry/rollup-plugin`, `@sentry/vite-plugin` or `@sentry/esbuild-plugin`.
-</li>
-<li>
-Requires SDK version `7.59.0` or higher.
-</li>
-</ul>
+  <ul>
+    <li>
+      Requires version `2.18.0` or higher of `@sentry/webpack-plugin`,
+      `@sentry/rollup-plugin`, `@sentry/vite-plugin` or
+      `@sentry/esbuild-plugin`.
+    </li>
+    <li>Requires SDK version `7.59.0` or higher.</li>
+  </ul>
 </Note>
 
 First, to identify the source of an error, you must inject metadata that helps identify
 which bundles were responsible for the error. You can do this with any of the
-Sentry bundler plugins by enabling the `_experiments.moduleMetadata` option. The example
+Sentry bundler plugins by enabling the `moduleMetadata` option. The example
 below is for Webpack, but this is also supported in Vite, Rollup, and esbuild.
 
 ```javascript
@@ -62,10 +62,7 @@ module.exports = {
   devtool: "source-map",
   plugins: [
     sentryWebpackPlugin({
-      /* Other plugin config */
-      _experiments: {
-        moduleMetadata: ({ release }) => ({ dsn: "__MODULE_DSN__", release }),
-      },
+      moduleMetadata: ({ release }) => ({ dsn: "__MODULE_DSN__", release }),
     }),
   ],
 };
@@ -82,7 +79,12 @@ for the multiplexed transport to reference for routing.
 In practice, here is what your Sentry initialization should look like:
 
 ```javascript
-import { init, makeFetchTransport, moduleMetadataIntegration, makeMultiplexedTransport } from "@sentry/browser";
+import {
+  init,
+  makeFetchTransport,
+  moduleMetadataIntegration,
+  makeMultiplexedTransport,
+} from "@sentry/browser";
 
 const EXTRA_KEY = "ROUTE_TO";
 
@@ -127,16 +129,13 @@ init({
 
 Once this is set up, errors - both handled and unhandled - will be automatically routed to the right project.
 
-
 ## Manually Route Errors to Different Projects
 
 If, however, you would like to have more control over the routing of errors to the point
 where you explicitly specify the destination for each individual `captureException`,
 you can do that with the more advanced interface multiplexed transport offers.
 
-<Note>
-Requires SDK version `7.59.0` or higher.
-</Note>
+<Note>Requires SDK version `7.59.0` or higher.</Note>
 
 The example below uses a `feature` tag to determine which Sentry project to
 send the event to. If the event does not have a `feature` tag, we send it to the
@@ -180,7 +179,13 @@ init({
 You can then set tags/contexts on events in individual micro-frontends to decide which Sentry project to send the event to as follows:
 
 <Note>
-It is important to always use a local scope when setting the tag (either as shown below or using <PlatformLink to="/enriching-events/scopes/#local-scopes">withScope documentation</PlatformLink>). Using a global scope e.g. through `Sentry.setTag()` will result in all subsequent events being routed to the same DSN regardless of where they originate.
+  It is important to always use a local scope when setting the tag (either as
+  shown below or using{" "}
+  <PlatformLink to="/enriching-events/scopes/#local-scopes">
+    withScope documentation
+  </PlatformLink>
+  ). Using a global scope e.g. through `Sentry.setTag()` will result in all subsequent
+  events being routed to the same DSN regardless of where they originate.
 </Note>
 
 ```