docs(providers): improve formatting & use new undocs components

docs/2.deploy/20.providers/alwaysdata.md

@@ -29,9 +29,11 @@
    - *Command*: `node ./output/server/index.mjs`
    - *Working directory*: `www/my-app` (adapt it to your deployment path)
    - *Environment*:
+
      ```ini
      NITRO_PRESET=alwaysdata
      ```
+
    - *Node.js version*: `Default version` is fine; pick no less than `20.0.0` (you can also [set your Node.js version globally](https://help.alwaysdata.com/en/languages/nodejs/configuration/#supported-versions))
    - *Hot restart*: `SIGHUP`
 

docs/2.deploy/20.providers/aws-amplify.md

@@ -19,12 +19,12 @@ Integration with this provider is possible with [zero configuration](/deploy/#ze
 5. Optionally, select Enable SSR logging to enable server-side logging to your Amazon CloudWatch account
 6. Confirm configuration and click on "Save and Deploy"
 
-
 ## Advanced Configuration
 
 You can configure advanced options of this preset using `awsAmplify` option.
 
 ::code-group
+
 ```ts [nitro.config.ts]
 export default defineNitroConfig({
   awsAmplify: {
@@ -46,13 +46,15 @@ export default defineNuxtConfig({
   }
 })
 ```
+
 ::
 
 ### `amplify.yml`
 
 You might need a custom `amplify.yml` file for advanced configuration. Here are two template examples:
 
 ::code-group
+
 ```yml [amplify.yml]
 version: 1
 frontend:
@@ -89,4 +91,5 @@ applications:
       buildPath: /
     appRoot: apps/website1
 ```
+
 ::

docs/2.deploy/20.providers/aws.md

@@ -23,16 +23,19 @@ const { statusCode, headers, body } = handler({ rawPath: '/' })
 Nitro output, by default uses dynamic chunks for lazy loading code only when needed. However this sometimes can not be ideal for performance. (See discussions in [unjs/nitro#650](https://github.com/unjs/nitro/pull/650)). You can enabling chunk inlining behavior using [`inlineDynamicImports`](/config#inlinedynamicimports) config.
 
 ::code-group
+
 ```ts [nitro.config.ts]
 export default defineNitroConfig({
   inlineDynamicImports: true
 });
 ```
+
 ```ts [nuxt.config.ts]
 export default defineNuxtConfig({
   nitro: {
     inlineDynamicImports: true
   }
 })
 ```
+
 ::

docs/2.deploy/20.providers/azure.md

@@ -21,7 +21,7 @@ Install [Azure Functions Core Tools](https://docs.microsoft.com/en-us/azure/azur
 You can invoke a development environment to preview before deploying.
 
 ```bash
-NITRO_PRESET=azure yarn build
+NITRO_PRESET=azure npx nypm@latest build
 npx @azure/static-web-apps-cli start .output/public --api-location .output/server
 ```
 
@@ -58,9 +58,7 @@ When you are asked to select your framework, select custom and provide the follo
 
 If you miss this step, you can always find the build configuration section in your workflow and update the build configuration:
 
-```yaml
-# .github/workflows/azure-static-web-apps-<RANDOM_NAME>.yml
-
+```yaml [.github/workflows/azure-static-web-apps-<RANDOM_NAME>.yml]
 ###### Repository/Build Configurations ######
 app_location: '/'
 api_location: '.output/server'
@@ -88,7 +86,7 @@ Install [Azure Functions Core Tools](https://docs.microsoft.com/en-us/azure/azur
 You can invoke a development environment from the serverless directory.
 
 ```bash
-NITRO_PRESET=azure_functions yarn build
+NITRO_PRESET=azure_functions npx nypm@latest build
 cd .output
 func start
 ```
@@ -112,8 +110,7 @@ First, obtain your Azure Functions Publish Profile and add it as a secret to you
 
 Then create the following file as a workflow:
 
-```yaml
-# .github/workflows/azure.yml
+```yaml [.github/workflows/azure.yml]
 name: azure
 on:
   push:

docs/2.deploy/20.providers/cleavr.md

@@ -10,7 +10,6 @@
 Integration with this provider is possible with [zero configuration](/deploy/#zero-config-providers).
 ::
 
-
 ## Set up your web app
 
 In your project, set Nitro preset to `cleavr`.
@@ -22,6 +21,7 @@ export default {
   }
 }
 ```
+
 Push changes to your code repository.
 
 **In your Cleavr panel:**

docs/2.deploy/20.providers/cloudflare.md

@@ -16,7 +16,6 @@ This is the recommended preset for Cloudflare deployments, please consider using
 Integration with this provider is possible with zero configuration.
 ::
 
-
 Nitro automatically generates a `_routes.json` file that controls which routes get served from files and which are served from the Worker script. The auto-generated routes file can be overridden with the config option `cloudflare.pages.routes` ([read more](https://developers.cloudflare.com/pages/platform/functions/routing/#functions-invocation-routes)).
 
 ### Building your Application using the preset
@@ -28,49 +27,43 @@ If you use the [Cloudflare Pages GitHub/GitLab integration](https://developers.c
 If instead you want preview your application locally and/or manually deploy it, when building the application you will need to let Nitro know that the target environment is the Cloudflare Pages one, you can do that in two ways:
 
 1. By defining either the `NITRO_PRESET` or the `SERVER_PRESET` environment variable set to `cloudflare-pages` when running the build process, like so:
-```bash
-NITRO_PRESET=cloudflare-pages npm run build
-```
+
+  ```bash
+  NITRO_PRESET=cloudflare-pages npm run build
+  ```
 
 1. Or by updating your Nitro [preset configuration](/config#preset):
-```json5
-"preset": "cloudflare-pages",
-```
+
+  ```json5
+  "preset": "cloudflare-pages",
+  ```
+
 and then running the standard build command:
-```bash
-npm run build
-```
+
+:pm-run{script="build"}
 
 ### Wrangler
 
 To preview your application locally or manually deploy it you will need to use the [wrangler](https://github.com/cloudflare/workers-sdk/tree/main/packages/wrangler) CLI tool, simply install it as a node dependency:
 
-```bash
-npm i wrangler
-```
+:pm-install{name="wrangler"}
 
 ### Preview your app locally
 
 After having built your application you can preview it locally with wrangler by running:
 
-```bash
-npx wrangler pages dev dist
-```
+:pm-x{command="wrangler pages dev dist"}
 
 ### Deploy from your local machine using wrangler
 
 After having built your application you can manually deploy it with wrangler, in order to do so first make sure to be
 logged into your Cloudflare account:
 
-```bash
-npx wrangler login
-```
+:pm-x{command="wrangler login"}
 
 Then you can deploy the application with:
 
-```bash
-npx wrangler pages deploy dist
-```
+:pm-x{command="wrangler pages deploy dist"}
 
 ## Cloudflare Module Workers
 
@@ -145,9 +138,7 @@ npx wrangler dev .output/server/index.mjs --site .output/public
 
 and publish it:
 
-```bash
-npx wrangler deploy
-```
+:pm-x{command="npx wrangler deploy"}
 
 ## Cloudflare Service Workers
 
@@ -206,7 +197,6 @@ SECRET="top-secret"
 **Note:** Make sure you add `.env` to the `.gitignore` file so that you don't commit it as it can contain sensitive information.
 ::
 
-
 ### Specify Variables for local previews
 
 After build, when you try out your project locally with `wrangler dev` or `wrangler pages dev`, in order to have access to environment variables you will need to specify the in a `.dev.vars` file in the root of your project (as presented in the [Pages](https://developers.cloudflare.com/pages/functions/bindings/#interact-with-your-environment-variables-locally) and [Workers](https://developers.cloudflare.com/workers/configuration/environment-variables/#interact-with-environment-variables-locally) documentation).
@@ -217,7 +207,6 @@ If you are using a `.env` file while developing, your `.dev.vars` should be iden
 **Note:** Make sure you add `.dev.vars` to the `.gitignore` file so that you don't commit it as it can contain sensitive information.
 ::
 
-
 ### Specify Variables for Production
 
 For production, use the cloudflare dashboard or the [`wrangler secret`](https://developers.cloudflare.com/workers/wrangler/commands/#secret) command to set environment variables and secrets.
@@ -281,6 +270,7 @@ In order to access bindings during local dev mode, regardless of the chosen pres
 > The `nitro-cloudflare-dev` module is experimental. The Nitro team is looking into a more native integration  which could in the near future make the module unneeded.
 
 In order to access bindings in dev mode we start by defining the bindings in a `wrangler.toml` file, this is for example how you would define a variable and a KV namespace:
+
 ```ini [wrangler.toml]
 [vars]
 MY_VARIABLE="my-value"
@@ -291,7 +281,7 @@ id = "xxx"
 ```
 
 > [!NOTE]
->  Only bindings in the default environment are recognized.
+> Only bindings in the default environment are recognized.
 
 Next we install the `nitro-cloudflare-dev` module as well as the required `wrangler` package (if not already installed):
 
@@ -300,18 +290,21 @@ Next we install the `nitro-cloudflare-dev` module as well as the required `wrang
 Then define module:
 
 ::code-group
+
 ```js [nitro.config.js]
 import nitroCloudflareBindings from "nitro-cloudflare-dev";
 
 export default defineNitroConfig({
   modules: [nitroCloudflareBindings],
 });
 ```
+
 ```ts [nuxt.config.ts]
 export default defineNuxtConfig({
   modules: ['nitro-cloudflare-dev']
 })
 ```
+
 ::
 
 From this moment, when running

docs/2.deploy/20.providers/deno-deploy.md

@@ -25,11 +25,11 @@ deployctl deploy --project=my-project server/index.ts
 
 You just need to include the deployctl GitHub Action as a step in your workflow.
 
-You do not need to set up any secrets for this to work. You do need to link your GitHub repository to your Deno Deploy project and choose the "GitHub Actions" deployment mode. You can do this in your project settings on https://dash.deno.com.
+You do not need to set up any secrets for this to work. You do need to link your GitHub repository to your Deno Deploy project and choose the "GitHub Actions" deployment mode. You can do this in your project settings on https://dash.deno.com
 
-Create `.github/workflows/deno_deploy.yml`:
+Create the following workflow file in your `.github/workflows` directory:
 
-```yaml
+```yaml [.github/workflows/deno_deploy.yml]
 name: deno-deploy
 
 on:

docs/2.deploy/20.providers/digitalocean.md

@@ -30,7 +30,6 @@
 
    [See more information](https://docs.digitalocean.com/products/app-platform/languages-frameworks/nodejs/#node-version).
 
-
 1. You'll also need to add a run command so Digital Ocean knows what command to run after a build. You can do so by adding a start script to your `package.json`:
 
    ```json