docs: normalize code blocks and add filename attributes

pages/aws/common_issues.mdx

@@ -4,7 +4,7 @@ OpenNext can be executed in debug mode by setting the environment variable `OPEN
 
 This will output **A LOT** of additional logs to the console.This also disable minifying in esbuild, and add source maps to the output. This can result in code that might be up to 2-3X larger than the production build. **Do not enable this in production**
 
-```bash
+```sh
 OPEN_NEXT_DEBUG=true npx open-next@latest build
 ```
 
@@ -16,7 +16,7 @@ You might stumble upon this error inside cloudwatch logs: `Cannot find module 'n
 
 Next might incorrectly include some dependencies in the bundle. To remove them you can use this configuration inside `next.config.js`:
 
-```javascript
+```js filename="next.config.js"
 outputFileTracingExcludes: { // or experimental.outputFileTracingExcludes on Next < 15
   "*": ["node_modules/the-unwanted-package"],
 },
@@ -39,7 +39,7 @@ For example, Sentry does not remove server side sourcemaps, only client ones, ev
 
 You could exclude sourcemaps similarly:
 
-```javascript
+```js filename="next.config.js"
 outputFileTracingExcludes: {
   "*": [
     './**/*.js.map',
@@ -96,9 +96,7 @@ The config recommended by Sentry docs uses dynamic imports in `instrumentation.t
 
 Here's a working Sentry config which resolves the error:
 
-`instrumentation.ts`
-
-```typescript
+```ts filename="instrumentation.ts"
 import * as Sentry from "@sentry/nextjs";
 import { initSentry } from "../sentry.server.config";
 
@@ -109,9 +107,7 @@ export async function register() {
 }
 ```
 
-`sentry.server.config.ts`
-
-```typescript
+```ts filename="sentry.server.config.ts"
 import * as Sentry from "@sentry/nextjs";
 
 export const initSentry = (runtime: "nodejs" | "edge") => {
@@ -141,7 +137,7 @@ If you are not using `yarn` and you see `yarn` related errors it might be solved
 Sometimes there might be a file missing from your server functions bundle. An example could be `sentry.server.config.ts`. It can be any file or directory and it also accept globs. In Next there is an option to include files that were not picked up by tracing.
 Its called `outputFileTracingIncludes`. Here is an example on how to use it in `next.config.ts`:
 
-```ts
+```ts filename="next.config.ts"
 import type { NextConfig } from "next";
 
 const nextConfig: NextConfig = {
@@ -162,8 +158,7 @@ To read more about `outputFileTracingIncludes` you can refer to the [Next.js doc
 It works with function splitting in OpenNext aswell. If your key corresponds to a specific route (i.e: `api/test`), it will be included only in the function bundle for that route.
 Using `*` as a key, however, will include it in every function bundle. Here is an example with function splitting:
 
-```ts
-// open-next.config.ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next";
 const config = {
   default: {},
@@ -178,8 +173,9 @@ const config = {
     },
   },
 } satisfies OpenNextConfig;
+```
 
-// next.config.ts
+```ts filename="next.config.ts"
 import type { NextConfig } from "next";
 
 const nextConfig: NextConfig = {

pages/aws/config.mdx

@@ -13,7 +13,7 @@ This file needs to be placed at the same level as your `next.config.js` file.
 
 If you have an `open-next.config.ts` file, make sure you have atleast this:
 
-```ts
+```ts filename="open-next.config.ts"
 export default {
   default: {},
 };
@@ -29,7 +29,7 @@ If you want to look at a full example, you can check [the full example](/aws/con
 
 By default Next.js will add the [`x-powered-by`](https://nextjs.org/docs/app/api-reference/config/next-config-js/poweredByHeader) header. OpenNext will also add a header `x-opennext`. To opt-out of this, open `next.config.js` and disable the poweredByHeader property in the configuration:
 
-```ts
+```js filename="next.config.js"
 module.exports = {
   poweredByHeader: false,
 };

pages/aws/config/custom_overrides.mdx

@@ -4,7 +4,7 @@ In some cases the simple example is not enough, and you want to add more customi
 
 <Callout>
 Be careful if you use the edge runtime (either in a function or by using the external middleware), we do 2 compilations of the `open-next.config.ts`, one for node and one for the edge runtime. If you're using some custom overrides, you likely want to add
-```ts
+```ts filename="open-next.config.ts"
 edgeExternals: ['./customWrapper', './anyOtherOverrideUsed']
 ```
 to your `open-next.config.ts` to avoid the edge runtime to try to compile overrides that are not compatible with the edge runtime.
@@ -17,8 +17,7 @@ Sometimes you might want to modify the object received by OpenNext. For example
 
 You'll still have to use a fallback value during dev as this is not used by the dev server.
 
-```ts
-// customConverter.ts
+```ts filename="customConverter.ts"
 import converter from "@opennextjs/aws/overrides/converters/aws-apigw-v2.js";
 import type { Converter } from "@opennextjs/aws/types/overrides.js";
 import { Config } from "sst/node/Config";
@@ -50,8 +49,7 @@ export default {
 } as Converter;
 ```
 
-```ts
-// open-next.config.ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 
 const config = {
@@ -69,8 +67,7 @@ Here we provide a few examples for some custom wrapper.
 
 ### Define a global to use node in the middleware
 
-```ts
-// customWrapper.ts
+```ts filename="customWrapper.ts"
 import defaultWrapper from "@opennextjs/aws/overrides/wrappers/aws-lambda.js";
 
 //Here you can define some globals
@@ -87,8 +84,7 @@ globalThis.myApi = async () => {
 export default defaultWrapper;
 ```
 
-```ts
-// open-next.config.ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {
@@ -102,8 +98,7 @@ export default config;
 
 But since Next dev server runs in a fake edge runtime and that the global is defined only for deployment, you'll have to mock the global in your middleware.
 
-```ts
-// middleware.ts
+```ts filename="middleware.ts"
 import { NextResponse } from "next/server";
 import type { NextRequest } from "next/server";
 
@@ -135,8 +130,7 @@ export function middleware(request: NextRequest) {
 
 ### Use middy.js with the wrapper
 
-```ts
-// customWrapper.ts
+```ts filename="customWrapper.ts"
 import streamingWrapper from "@opennextjs/aws/overrides/wrappers/aws-lambda.js";
 import type { WrapperHandler } from "@opennextjs/aws/types/overrides.js";
 import middy from "@middy/core";
@@ -154,8 +148,7 @@ export default {
 };
 ```
 
-```ts
-// open-next.config.ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {
@@ -173,8 +166,7 @@ In this example the custom wrapper is used to preload some important routes befo
 
 **WARNING**: This one is not properly tested. It's just an example of what you could do. You should test it properly before using it in production. Also preloading too many routes is probably a bad idea.
 
-```ts
-// customWrapper.ts
+```ts filename="customWrapper.ts"
 import type { APIGatewayProxyEventV2, APIGatewayProxyResultV2 } from "aws-lambda";
 import { Writable } from "node:stream";
 
@@ -251,8 +243,7 @@ export default {
 };
 ```
 
-```ts
-// open-next.config.ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {
@@ -267,7 +258,7 @@ const config = {
 
 You can take inspiration from our [`fs-dev`](https://github.com/opennextjs/opennextjs-aws/blob/main/packages/open-next/src/overrides/incrementalCache/fs-dev.ts) override which uses the file system to store the incremental cache. You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.ts";
 const config = {
   default: {
@@ -287,7 +278,7 @@ export default config;
 
 By default it will use SQS queue to revalidate stale routes. You can read more about this [here](/aws/config/overrides/queue). To create your own custom override you can take inspiration by looking at our [included](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/queue) implementations. You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.ts";
 const config = {
   default: {
@@ -307,7 +298,7 @@ export default config;
 
 To override the tag cache you can take inspiration by looking at the [`fs-dev`](https://github.com/opennextjs/opennextjs-aws/blob/main/packages/open-next/src/overrides/tagCache/fs-dev.ts) override that uses the filesystem. You can read more about this override [here](/aws/config/overrides/tag_cache). You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.ts";
 const config = {
   default: {
@@ -327,7 +318,7 @@ export default config;
 
 This override is only used internally by OpenNext to resolve the origin of the request if you have an `external` middleware. You can take inspiration from looking at our included [`pattern-env`](https://github.com/opennextjs/opennextjs-aws/blob/main/packages/open-next/src/overrides/originResolver/pattern-env.ts) override. You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {},
@@ -348,7 +339,7 @@ export default config;
 
 This override is used in the image optimization server to load an image from a custom source. You can look at our implemention of using the file system [here](https://github.com/opennextjs/opennextjs-aws/blob/main/packages/open-next/src/overrides/imageLoader/fs-dev.ts). You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {},
@@ -366,7 +357,7 @@ export default config;
 
 To have a custom override for the warmer invoke you can take inspiration by looking at our [`aws-lambda`](https://github.com/opennextjs/opennextjs-aws/blob/main/packages/open-next/src/overrides/warmer/aws-lambda.ts) override. You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {},
@@ -384,7 +375,7 @@ export default config;
 
 To have a custom override for the CDN Invalidation you can take inspiration by looking at our [`cloudfront`](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/cdnInvalidation/cloudfront.ts) override. You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {
@@ -403,7 +394,7 @@ export default config;
 
 This is used by OpenNext to proxy rewritten requests to external services. You can read more about it [here](/aws/config/overrides/proxy_external_request). To have a custom override for the External Request Proxy you can take inspiration by looking at our [`fetch`](https://github.com/opennextjs/opennextjs-aws/blob/main/packages/open-next/src/overrides/proxyExternalRequest/fetch.ts) override. You need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {
@@ -422,7 +413,7 @@ export default config;
 
 This is used by OpenNext to resolve static assets. You can read more about it [here](/aws/config/overrides/asset_resolver). To have a custom override for the Asset Resolver, you need an `open-next.config.ts` with this:
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
 const config = {
   default: {},

pages/aws/config/full_example.mdx

@@ -4,7 +4,7 @@ Here is a detailed example of an `open-next.config.ts` file. This file need to b
 
 For more information about the options here, take a look at the [reference section](/aws/config/reference).
 
-```ts
+```ts filename="open-next.config.ts"
 import type { OpenNextConfig } from "@opennextjs/aws/types/open-next";
 const config = {
   default: {

pages/aws/config/nx.mdx

@@ -6,7 +6,7 @@ Here's a detailed exampled of how to add OpenNext + SST to an existing Nx worksp
 
 2. Update your `apps/next-site/next.config.js` add `output: ‘standalone’`, and you want to add `experimental.outputFileTracingRoot`, it should look a little like this:
 
-```javascript
+```js filename="next.config.js"
 //@ts-check
 
 // eslint-disable-next-line @typescript-eslint/no-var-requires
@@ -39,15 +39,15 @@ module.exports = composePlugins(...plugins)(nextConfig);
 
 3. Create `open-next.config.ts` inside your apps root directory, it should look a little something like this:
 
-```javascript
-import type { OpenNextConfig } from '@opennextjs/aws/types/open-next';
+```ts filename="open-next.config.ts"
+import type { OpenNextConfig } from "@opennextjs/aws/types/open-next";
 
 const config = {
   default: {},
-  buildCommand: 'exit 0', // in my example we set up Nx task distribution to handle the order of building.
-  buildOutputPath: '.',
-  appPath: '.',
-  packageJsonPath: '../../', // again, path to the root of your repo (where the package.json is)
+  buildCommand: "exit 0", // in my example we set up Nx task distribution to handle the order of building.
+  buildOutputPath: ".",
+  appPath: ".",
+  packageJsonPath: "../../", // again, path to the root of your repo (where the package.json is)
 } satisfies OpenNextConfig;
 
 export default config;
@@ -134,7 +134,7 @@ but we will not use the SST cli to init this project, because it wants to add a
 - let's add the sst package with `pnpm add sst@ion`, and the required packages for SST to work with AWS `pnpm add --save-dev aws-cdk-lib constructs @types/aws-lambda`
 - then we want to manually create an `sst.config.ts` file in `apps/next-site` that looks like this:
 
-```typescript
+```ts filename="sst.config.ts"
 /// <reference path="./.sst/platform/config.d.ts" />
 
 export default $config({
@@ -155,7 +155,7 @@ export default $config({
 
 - now, you probably see some type errors, as SST is not initialized yet, but we can resolve this by running
 
-```bash
+```sh
 $ cd apps/next-site && sst install
 ```
 
@@ -252,7 +252,7 @@ this will resolve the type issues and initialize SST.
 
 now we can run (or if you want a custom stage, you can simply do `nx deploy next-site --stage this-is-my-stage` and it will be passed directly to the sst command).
 
-```bash
+```sh
 $ nx deploy next-site --configuration dev # using dev configuration (which sets the stage to development)
 # nx deploy next-site -c dev # OR
 # nx deploy next-site --stage my-stage # Custom Stage

pages/aws/config/reference.mdx

@@ -81,7 +81,7 @@ Each server config will be under it's own key in the config object. Here are all
 
       Here is an example of how to install sharp on your default server function with ARM64 architecture:
 
-      ```ts
+      ```ts filename="open-next.config.ts"
       import type { OpenNextConfig } from '@opennextjs/aws/types/open-next';
       const config = {
       default: {