[aws]: refactor docs

pages/aws/common_issues.mdx

@@ -99,3 +99,16 @@ export const initSentry = (runtime: "nodejs" | "edge") => {
   });
 };
 ```
+
+#### Empty body in response when streaming in AWS Lambda
+
+We have seen trouble in the past with streaming hanging in AWS Lambda when the response body is empty.
+We currently have a workaround in OpenNext for this by setting the environment variable `OPEN_NEXT_FORCE_NON_EMPTY_RESPONSE` to `true`.
+This will write something to the stream to make sure it is not empty.
+
+#### The Yarn Plug'n'Play manifest forbids importing "xxx" here because it's not listed as a dependency of this package
+
+This error is usually resolved by removing all yarn files in your repo. You should also look in your `package.json` and see if you have `yarn` set as `packageManager` there. Removing it will solve the issue.
+If you use `yarn` there is a workaround [here](https://stackoverflow.com/a/76902985https://stackoverflow.com/a/76902985).
+
+If you are not using `yarn` and you see `yarn` related errors it might be solved by running `corepack disable` or updating `nvm` to `0.40.2`.

pages/aws/comparison.mdx

@@ -1,4 +1,4 @@
-It should be noted that open-next does not actually deploy the app. It only bundles everything for your IAC to deploy it.
+It should be noted that OpenNext does not actually deploy the app. It only bundles everything for your IAC to deploy it.
 
 Here is a table comparing the different options to deploy a next.js app:
 

pages/aws/inner_workings.mdx

@@ -19,5 +19,5 @@ my-next-app/
     revalidation-function/         -> Handler code for revalidation backend
     image-optimization-function/   -> Handler code for image optimization backend
     warmer-function/               -> Cron job code to keep server function warm - Not mandatory
-    dynamo-provider/               -> Code for a custom resource to populate the Tag Cache - Only necessary for app dir
+    dynamodb-provider/               -> Code for a custom resource to populate the Tag Cache - Only necessary for app dir
 ```

pages/aws/inner_workings/caching.mdx

@@ -1,6 +1,6 @@
 ## Caching in Next and OpenNext
 
-Caching could be become tricky very fast when using Next outside of Vercel. There is a lot of things that need to be taken into account.
+Caching could become tricky very fast when using Next outside of Vercel. There is a lot of things that need to be taken into account.
 
 Usually, you'll deploy your Next app with a CDN in front of it. This CDN will cache the responses from your Next app and serve them to the users. This is great for performance, but it can also be a problem when you need to invalidate the cache. We provide some code examples in this doc to help with [cloudfront cache invalidation](#cloudfront-cache-invalidation). **In OpenNext, you only need to do this if you do On Demand Revalidation**.
 

pages/aws/inner_workings/routing.mdx

@@ -19,3 +19,19 @@ Here is a list of features that OpenNext routing system handle:
 #### Next Middleware
 
 The Next middleware in OpenNext is not running in the same way as in Next.js. In Next.js, the middleware is running inside the `NextServer` inside a fake edge runtime. In OpenNext, we modify the middleware and run it fully inside the routing layer. So if you run the routing layer in Node, you can use Node api inside the middleware (it's a bit tricky because it won't work with `next dev` and involves some workaround because Next will remove Node api during bundling. Some example [here](/aws/config/custom_overrides#define-a-global-to-use-node-in-the-middleware)).
+
+On latest Next 15(works with latest OpenNext aswell) you can now add an `experimental` setting in `next.config.ts` to enable `nodejs` as the runtime for the middleware:
+
+```ts
+const nextConfig: NextConfig = {
+  experimental: {
+    nodeMiddleware: true,
+  },
+};
+// and then in your `middleware.ts` you put:
+export const config = {
+  runtime: "nodejs",
+};
+```
+
+Here is the [PR](https://github.com/vercel/next.js/pull/75624) that introduced this feature in Next.