Simplify example

src/platforms/javascript/common/configuration/micro-frontend-support.mdx

@@ -11,10 +11,9 @@ those specific projects.
 ## Identifying responsible modules
 
 The help identify modules, we can inject metadata into them which can
-later be used to identify which bundles were responsible for an error.
-
-This can be achieved using `@sentry/webpack-plugin` via the
-`_experiments.moduleMetadata` option.
+later be used to identify which bundles were responsible for an error. This can
+be achieved using `@sentry/webpack-plugin` via the `_experiments.moduleMetadata`
+option.
 
 Requires version `2.5.0` or higher of `@sentry/webpack-plugin`.
 
@@ -82,14 +81,13 @@ Sentry.captureException(new Error("oh no!"));
 ## Routing events to different projects
 
 Once you've identified which module or modules are likely to be responsible for
-an error, you may want to send these events to different Sentry projects.
-
-This can be achieved using the multiplexed transport which can send events to
-different Sentry projects based on the attributes on an event.
+an error, you may want to send these events to different Sentry projects. The
+multiplexed transport can send events to different Sentry projects based on the
+attributes on an event.
 
 Requires SDK version `7.50.0` or higher.
 
-The example below uses the `feature` tag to determine which Sentry project to
+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
 fallback DSN defined in `Sentry.init`.
 
@@ -210,7 +208,7 @@ const transport = makeMultiplexedTransport(makeFetchTransport, args => {
   return [];
 });
 
-Sentry.init({
+init({
   dsn: '__DEFAULT_DSN__',
   integrations: [new ModuleMetadata()],
   transport,