@nuxt/docs 4.1.1 → 4.1.3

package/2.guide/{1.concepts → 2.concepts}/1.auto-imports.md

@@ -11,25 +11,25 @@ const count = ref(1) // ref is auto-imported
 </script>
 ```
 
-Thanks to its opinionated directory structure, Nuxt can auto-import your [`app/components/`](/docs/guide/directory-structure/app/components), [`app/composables/`](/docs/guide/directory-structure/app/composables) and [`app/utils/`](/docs/guide/directory-structure/app/utils).
+Thanks to its opinionated directory structure, Nuxt can auto-import your [`app/components/`](/docs/4.x/guide/directory-structure/app/components), [`app/composables/`](/docs/4.x/guide/directory-structure/app/composables) and [`app/utils/`](/docs/4.x/guide/directory-structure/app/utils).
 
 Contrary to a classic global declaration, Nuxt preserves typings, IDEs completions and hints, and **only includes what is used in your production code**.
 
 ::note
-In the docs, every function that is not explicitly imported is auto-imported by Nuxt and can be used as-is in your code. You can find a reference for auto-imported components, composables and utilities in the [API section](/docs/api).
+In the docs, every function that is not explicitly imported is auto-imported by Nuxt and can be used as-is in your code. You can find a reference for auto-imported components, composables and utilities in the [API section](/docs/4.x/api).
 ::
 
 ::note
-In the [`server`](/docs/guide/directory-structure/server) directory, Nuxt auto-imports exported functions and variables from `server/utils/`.
+In the [`server`](/docs/4.x/guide/directory-structure/server) directory, Nuxt auto-imports exported functions and variables from `server/utils/`.
 ::
 
 ::note
-You can also auto-import functions exported from custom folders or third-party packages by configuring the [`imports`](/docs/api/nuxt-config#imports) section of your `nuxt.config` file.
+You can also auto-import functions exported from custom folders or third-party packages by configuring the [`imports`](/docs/4.x/api/nuxt-config#imports) section of your `nuxt.config` file.
 ::
 
 ## Built-in Auto-imports
 
-Nuxt auto-imports functions and composables to perform [data fetching](/docs/getting-started/data-fetching), get access to the [app context](/docs/api/composables/use-nuxt-app) and [runtime config](/docs/guide/going-further/runtime-config), manage [state](/docs/getting-started/state-management) or define components and plugins.
+Nuxt auto-imports functions and composables to perform [data fetching](/docs/4.x/getting-started/data-fetching), get access to the [app context](/docs/4.x/api/composables/use-nuxt-app) and [runtime config](/docs/4.x/guide/going-further/runtime-config), manage [state](/docs/4.x/getting-started/state-management) or define components and plugins.
 
 ```vue twoslash
 <script setup lang="ts">
@@ -66,7 +66,7 @@ If you get an error message like `Nuxt instance is unavailable` then it probably
 When using a composable that requires the Nuxt context inside a non-SFC component, you need to wrap your component with `defineNuxtComponent` instead of `defineComponent`
 ::
 
-::read-more{to="/docs/guide/going-further/experimental-features#asynccontext" icon="i-lucide-star"}
+::read-more{to="/docs/4.x/guide/going-further/experimental-features#asynccontext" icon="i-lucide-star"}
 Checkout the `asyncContext` experimental feature to use Nuxt composables in async functions.
 ::
 
@@ -101,11 +101,11 @@ export const useMyComposable = () => {
 
 Nuxt directly auto-imports files created in defined directories:
 
-- `app/components/` for [Vue components](/docs/guide/directory-structure/app/components).
-- `app/composables/` for [Vue composables](/docs/guide/directory-structure/app/composables).
+- `app/components/` for [Vue components](/docs/4.x/guide/directory-structure/app/components).
+- `app/composables/` for [Vue composables](/docs/4.x/guide/directory-structure/app/composables).
 - `app/utils/` for helper functions and other utilities.
 
-:link-example{to="/docs/examples/features/auto-imports"}
+:link-example{to="/docs/4.x/examples/features/auto-imports"}
 
 ::warning
 **Auto-imported `ref` and `computed` won't be unwrapped in a component `<template>`.** :br
@@ -120,7 +120,7 @@ Nuxt exposes every auto-import with the `#imports` alias that can be used to mak
 
 ```vue
 <script setup lang="ts">
-import { ref, computed } from '#imports'
+import { computed, ref } from '#imports'
 
 const count = ref(1)
 const double = computed(() => count.value * 2)
@@ -134,12 +134,12 @@ If you want to disable auto-importing composables and utilities, you can set `im
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   imports: {
-    autoImport: false
-  }
+    autoImport: false,
+  },
 })
 ```
 
-This will disable auto-imports completely but it's still possible to use [explicit imports](#explicit-imports) from `#imports`.
+This will disable auto-imports completely but it's still possible to use [explicit imports](/docs/4.x/guide/concepts/auto-imports#explicit-imports) from `#imports`.
 
 ### Partially Disabling Auto-imports
 
@@ -148,8 +148,8 @@ If you want framework-specific functions like `ref` to remain auto-imported but
 ```ts
 export default defineNuxtConfig({
   imports: {
-    scan: false
-  }
+    scan: false,
+  },
 })
 ```
 
@@ -167,15 +167,15 @@ With this configuration:
 
 Nuxt also automatically imports components from your `~/components` directory, although this is configured separately from auto-importing composables and utility functions.
 
-:read-more{to="/docs/guide/directory-structure/app/components"}
+:read-more{to="/docs/4.x/guide/directory-structure/app/components"}
 
 To disable auto-importing components from your own `~/components` directory, you can set `components.dirs` to an empty array (though note that this will not affect components added by modules).
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   components: {
-    dirs: []
-  }
+    dirs: [],
+  },
 })
 ```
 
@@ -195,10 +195,10 @@ export default defineNuxtConfig({
     presets: [
       {
         from: 'vue-i18n',
-        imports: ['useI18n']
-      }
-    ]
-  }
+        imports: ['useI18n'],
+      },
+    ],
+  },
 })
 ```
 

package/2.guide/{1.concepts → 2.concepts}/10.nuxt-lifecycle.md

@@ -22,7 +22,7 @@ When Nitro starts, it initializes and executes the plugins under the `/server/pl
 Nitro plugins are executed only once when the server starts. In a serverless environment, the server boots on each incoming request, and so do the Nitro plugins. However, they are not awaited.
 ::
 
-:read-more{to="/docs/guide/directory-structure/server#server-plugins"}
+:read-more{to="/docs/4.x/guide/directory-structure/server#server-plugins"}
 
 ### Step 2: Nitro Server Middleware
 
@@ -32,7 +32,7 @@ After initializing the Nitro server, middleware under `server/middleware/` is ex
 Returning a value from middleware will terminate the request and send the returned value as the response. This behavior should generally be avoided to ensure proper request handling!
 ::
 
-:read-more{to="/docs/guide/directory-structure/server#server-middleware"}
+:read-more{to="/docs/4.x/guide/directory-structure/server#server-middleware"}
 
 ### Step 3: Initialize Nuxt and Execute Nuxt App Plugins
 
@@ -40,13 +40,13 @@ The Vue and Nuxt instances are created first. Afterward, Nuxt executes its serve
 - Built-in plugins, such as Vue Router and `unhead`.
 - Custom plugins located in the `app/plugins/` directory, including those without a suffix (e.g., `myPlugin.ts`) and those with the `.server` suffix (e.g., `myServerPlugin.server.ts`).
 
-Plugins execute in a specific order and may have dependencies on one another. For more details, including execution order and parallelism, refer to the [Plugins documentation](/docs/guide/directory-structure/plugins).
+Plugins execute in a specific order and may have dependencies on one another. For more details, including execution order and parallelism, refer to the [Plugins documentation](/docs/4.x/guide/directory-structure/plugins).
 
 ::callout{icon="i-lucide-lightbulb"}
-After this step, Nuxt calls the [`app:created`](/docs/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
+After this step, Nuxt calls the [`app:created`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
 ::
 
-:read-more{to="/docs/guide/directory-structure/plugins"}
+:read-more{to="/docs/4.x/guide/directory-structure/plugins"}
 
 ### Step 4: Route Validation
 
@@ -55,9 +55,9 @@ After initializing plugins and before executing middleware, Nuxt calls the `vali
 - The `validate` function should return `true` if the parameters are valid.
 - If validation fails, it should return `false` or an object containing a `statusCode` and/or `statusMessage` to terminate the request.
 
-For more information, see the [Route Validation documentation](/docs/getting-started/routing#route-validation).
+For more information, see the [Route Validation documentation](/docs/4.x/getting-started/routing#route-validation).
 
-:read-more{to="/docs/getting-started/routing#route-validation"}
+:read-more{to="/docs/4.x/getting-started/routing#route-validation"}
 
 ### Step 5: Execute Nuxt App Middleware
 
@@ -70,11 +70,11 @@ In Nuxt, there are three types of middleware:
 
 Nuxt executes all global middleware on the initial page load (both on server and client) and then again before any client-side navigation. Named and anonymous middleware are executed only on the routes specified in the middleware property of the page(route) meta defined in the corresponding page components.
 
-For details about each type and examples, see the [Middleware documentation](/docs/guide/directory-structure/app/middleware).
+For details about each type and examples, see the [Middleware documentation](/docs/4.x/guide/directory-structure/app/middleware).
 
 Any redirection on the server will result in a `Location:` header being sent to the browser; the browser then makes a fresh request to this new location. All application state will be reset when this happens, unless persisted in a cookie.
 
-:read-more{to="/docs/guide/directory-structure/app/middleware"}
+:read-more{to="/docs/4.x/guide/directory-structure/app/middleware"}
 
 ### Step 6: Render Page and Components
 
@@ -99,11 +99,11 @@ Watch a video from Daniel Roe explaining Server Rendering and Global State.
 After all required data is fetched and the components are rendered, Nuxt combines the rendered components with settings from `unhead` to generate a complete HTML document. This HTML, along with the associated data, is then sent back to the client to complete the SSR process.
 
 ::callout{icon="i-lucide-lightbulb"}
-After rendering the Vue application to HTML, Nuxt calls the [`app:rendered`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
+After rendering the Vue application to HTML, Nuxt calls the [`app:rendered`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
 ::
 
 ::callout{icon="i-lucide-lightbulb"}
-Before finalizing and sending the HTML, Nitro will call the [`render:html`](/docs/api/advanced/hooks#nitro-app-hooks-runtime-server-side) hook. This hook allows you to manipulate the generated HTML, such as injecting additional scripts or modifying meta tags.
+Before finalizing and sending the HTML, Nitro will call the [`render:html`](/docs/4.x/api/advanced/hooks#nitro-app-hooks-runtime-server-side) hook. This hook allows you to manipulate the generated HTML, such as injecting additional scripts or modifying meta tags.
 ::
 
 ## Client (browser)
@@ -117,10 +117,10 @@ This step is similar to the server-side execution and includes both built-in and
 Custom plugins in the `app/plugins/` directory, such as those without a suffix (e.g., `myPlugin.ts`) and with the `.client` suffix (e.g., `myClientPlugin.client.ts`), are executed on the client side.
 
 ::callout{icon="i-lucide-lightbulb"}
-After this step, Nuxt calls the [`app:created`](/docs/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
+After this step, Nuxt calls the [`app:created`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
 ::
 
-:read-more{to="/docs/guide/directory-structure/plugins"}
+:read-more{to="/docs/4.x/guide/directory-structure/plugins"}
 
 ### Step 2: Route Validation
 
@@ -130,20 +130,20 @@ This step is the same as the server-side execution and includes the `validate` m
 
 Nuxt middleware runs on both the server and the client. If you want certain code to run in specific environments, consider splitting it by using `import.meta.client` for the client and `import.meta.server` for the server.
 
-:read-more{to="/docs/guide/directory-structure/app/middleware#when-middleware-runs"}
+:read-more{to="/docs/4.x/guide/directory-structure/app/middleware#when-middleware-runs"}
 
 ### Step 4: Mount Vue Application and Hydration
 
-Calling `app.mount('#__nuxt')` mounts the Vue application to the DOM. If the application uses SSR or SSG mode, Vue performs a hydration step to make the client-side application interactive. During hydration, Vue recreates the application (excluding [Server Components](/docs/guide/directory-structure/app/components#server-components)), matches each component to its corresponding DOM nodes, and attaches DOM event listeners.
+Calling `app.mount('#__nuxt')` mounts the Vue application to the DOM. If the application uses SSR or SSG mode, Vue performs a hydration step to make the client-side application interactive. During hydration, Vue recreates the application (excluding [Server Components](/docs/4.x/guide/directory-structure/app/components#server-components)), matches each component to its corresponding DOM nodes, and attaches DOM event listeners.
 
 To ensure proper hydration, it's important to maintain consistency between the data on the server and the client. For API requests, it is recommended to use `useAsyncData`, `useFetch`, or other SSR-friendly composables. These methods ensure that the data fetched on the server side is reused during hydration, avoiding repeated requests. Any new requests should only be triggered after hydration, preventing hydration errors.
 
 ::callout{icon="i-lucide-lightbulb"}
-Before mounting the Vue application, Nuxt calls the [`app:beforeMount`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
+Before mounting the Vue application, Nuxt calls the [`app:beforeMount`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
 ::
 
 ::callout{icon="i-lucide-lightbulb"}
-After mounting the Vue application, Nuxt calls the [`app:mounted`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
+After mounting the Vue application, Nuxt calls the [`app:mounted`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
 ::
 
 ### Step 5: Vue Lifecycle

package/2.guide/{1.concepts → 2.concepts}/2.vuejs-development.md

@@ -25,17 +25,17 @@ We chose to build Nuxt on top of Vue for these reasons:
 
 ### Auto-imports
 
-Every Vue component created in the [`app/components/`](/docs/guide/directory-structure/app/components) directory of a Nuxt project will be available in your project without having to import it. If a component is not used anywhere, your production’s code will not include it.
+Every Vue component created in the [`app/components/`](/docs/4.x/guide/directory-structure/app/components) directory of a Nuxt project will be available in your project without having to import it. If a component is not used anywhere, your production’s code will not include it.
 
-:read-more{to="/docs/guide/concepts/auto-imports"}
+:read-more{to="/docs/4.x/guide/concepts/auto-imports"}
 
 ### Vue Router
 
-Most applications need multiple pages and a way to navigate between them. This is called **routing**. Nuxt uses an [`app/pages/`](/docs/guide/directory-structure/app/pages) directory and naming conventions to directly create routes mapped to your files using the official [Vue Router library](https://router.vuejs.org).
+Most applications need multiple pages and a way to navigate between them. This is called **routing**. Nuxt uses an [`app/pages/`](/docs/4.x/guide/directory-structure/app/pages) directory and naming conventions to directly create routes mapped to your files using the official [Vue Router library](https://router.vuejs.org).
 
-:read-more{to="/docs/getting-started/routing"}
+:read-more{to="/docs/4.x/getting-started/routing"}
 
-:link-example{to="/docs/examples/features/auto-imports"}
+:link-example{to="/docs/4.x/examples/features/auto-imports"}
 
 ## Differences with Nuxt 2 / Vue 2
 
@@ -64,16 +64,16 @@ The only way to provide data and logic to components in Vue 2 was through the Op
 ```vue twoslash
 <script>
 export default {
-  data() {
+  data () {
     return {
-      count: 0
+      count: 0,
     }
   },
   methods: {
-    increment(){
+    increment () {
       this.count++
-    }
-  }
+    },
+  },
 }
 </script>
 ```
@@ -91,13 +91,13 @@ const increment = () => count.value++
 
 The goal of Nuxt is to provide a great developer experience around the Composition API.
 
-- Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core.html) from Vue and Nuxt [built-in composables](/docs/api/composables/use-async-data).
-- Write your own auto-imported reusable functions in the [`app/composables/` directory](/docs/guide/directory-structure/app/composables).
+- Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core.html) from Vue and Nuxt [built-in composables](/docs/4.x/api/composables/use-async-data).
+- Write your own auto-imported reusable functions in the [`app/composables/` directory](/docs/4.x/guide/directory-structure/app/composables).
 
 ### TypeScript Support
 
 Both Vue 3 and Nuxt 3+ are written in TypeScript. A fully typed codebase prevents mistakes and documents APIs usage. This doesn’t mean that you have to write your application in TypeScript to take advantage of it. With Nuxt 3, you can opt-in by renaming your file from `.js` to `.ts` , or add `<script setup lang="ts">` in a component.
 
-::read-more{to="/docs/guide/concepts/typescript"}
+::read-more{to="/docs/4.x/guide/concepts/typescript"}
 Read the details about TypeScript in Nuxt
 ::

package/2.guide/{1.concepts → 2.concepts}/3.rendering.md

@@ -3,11 +3,11 @@ title: 'Rendering Modes'
 description: 'Learn about the different rendering modes available in Nuxt.'
 ---
 
-Nuxt supports different rendering modes, [universal rendering](#universal-rendering), [client-side rendering](#client-side-rendering) but also offers [hybrid-rendering](#hybrid-rendering) and the possibility to render your application on [CDN Edge Servers](#edge-side-rendering).
+Nuxt supports different rendering modes, [universal rendering](/docs/4.x/guide/concepts/rendering#universal-rendering), [client-side rendering](/docs/4.x/guide/concepts/rendering#client-side-rendering) but also offers [hybrid-rendering](/docs/4.x/guide/concepts/rendering#hybrid-rendering) and the possibility to render your application on [CDN Edge Servers](/docs/4.x/guide/concepts/rendering#edge-side-rendering).
 
 Both the browser and server can interpret JavaScript code to turn Vue.js components into HTML elements. This step is called **rendering**. Nuxt supports both **universal** and **client-side** rendering. The two approaches have benefits and downsides that we will cover.
 
-By default, Nuxt uses **universal rendering** to provide better user experience, performance and to optimize search engine indexing, but you can switch rendering modes in [one line of configuration](/docs/api/nuxt-config#ssr).
+By default, Nuxt uses **universal rendering** to provide better user experience, performance and to optimize search engine indexing, but you can switch rendering modes in [one line of configuration](/docs/4.x/api/nuxt-config#ssr).
 
 ## Universal Rendering
 
@@ -25,24 +25,26 @@ It is normal to ask which parts of a Vue file runs on the server and/or the clie
 
 ```vue [app/app.vue]
 <script setup lang="ts">
-const counter = ref(0); // executes in server and client environments
+const counter = ref(0) // executes in server and client environments
 
 const handleClick = () => {
-  counter.value++; // executes only in a client environment
-};
+  counter.value++ // executes only in a client environment
+}
 </script>
 
 <template>
   <div>
     <p>Count: {{ counter }}</p>
-    <button @click="handleClick">Increment</button>
+    <button @click="handleClick">
+      Increment
+    </button>
   </div>
 </template>
 ```
 
 On the initial request, the `counter` ref is initialized in the server since it is rendered inside the `<p>` tag. The contents of `handleClick` is never executed here. During hydration in the browser, the `counter` ref is re-initialized. The `handleClick` finally binds itself to the button; Therefore it is reasonable to deduce that the body of `handleClick` will always run in a browser environment.
 
-[Middlewares](/docs/guide/directory-structure/app/middleware) and [pages](/docs/guide/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/guide/directory-structure/plugins) can be rendered on the server or client or both. [Components](/docs/guide/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/guide/directory-structure/app/composables) and [utilities](/docs/guide/directory-structure/app/utils) are rendered based on the context of their usage.
+[Middlewares](/docs/4.x/guide/directory-structure/app/middleware) and [pages](/docs/4.x/guide/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/4.x/guide/directory-structure/plugins) can be rendered on the server or client or both. [Components](/docs/4.x/guide/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/4.x/guide/directory-structure/app/composables) and [utilities](/docs/4.x/guide/directory-structure/app/utils) are rendered based on the context of their usage.
 
 **Benefits of server-side rendering:**
 - **Performance**: Users can get immediate access to the page's content because browsers can display static content much faster than JavaScript-generated content. At the same time, Nuxt preserves the interactivity of a web application during the hydration process.
@@ -50,7 +52,7 @@ On the initial request, the `counter` ref is initialized in the server since it
 
 **Downsides of server-side rendering:**
 - **Development constraints:** Server and browser environments don't provide the same APIs, and it can be tricky to write code that can run on both sides seamlessly. Fortunately, Nuxt provides guidelines and specific variables to help you determine where a piece of code is executed.
-- **Cost:** A server needs to be running in order to render pages on the fly. This adds a monthly cost like any traditional server. However, the server calls are highly reduced thanks to universal rendering with the browser taking over on client-side navigation. A cost reduction is possible by leveraging [edge-side-rendering](#edge-side-rendering).
+- **Cost:** A server needs to be running in order to render pages on the fly. This adds a monthly cost like any traditional server. However, the server calls are highly reduced thanks to universal rendering with the browser taking over on client-side navigation. A cost reduction is possible by leveraging [edge-side-rendering](/docs/4.x/guide/concepts/rendering#edge-side-rendering).
 
 Universal rendering is very versatile and can fit almost any use case, and is especially appropriate for any content-oriented websites: **blogs, marketing websites, portfolios, e-commerce sites, and marketplaces.**
 
@@ -83,20 +85,20 @@ You can enable client-side only rendering with Nuxt in your `nuxt.config.ts`:
 
 ```ts [nuxt.config.ts]
 export default defineNuxtConfig({
-  ssr: false
+  ssr: false,
 })
 ```
 
 ::note
 If you do use `ssr: false`, you should also place an HTML file in `~/spa-loading-template.html` with some HTML you would like to use to render a loading screen that will be rendered until your app is hydrated.
-:read-more{title="SPA Loading Template" to="/docs/api/configuration/nuxt-config#spaloadingtemplate"}
+:read-more{title="SPA Loading Template" to="/docs/4.x/api/configuration/nuxt-config#spaloadingtemplate"}
 ::
 
 :video-accordion{title="Watch a video from Alexander Lichter about Building a plain SPA with Nuxt" videoId="7Lr0QTP1Ro8"}
 
 ### Deploying a Static Client-Rendered App
 
-If you deploy your app to [static hosting](/docs/getting-started/deployment#static-hosting) with the `nuxt generate` or `nuxt build --prerender` commands, then by default, Nuxt will render every page as a separate static HTML file.
+If you deploy your app to [static hosting](/docs/4.x/getting-started/deployment#static-hosting) with the `nuxt generate` or `nuxt build --prerender` commands, then by default, Nuxt will render every page as a separate static HTML file.
 
 ::warning
 If you prerender your app with the `nuxt generate` or `nuxt build --prerender` commands, then you will not be able to use any server endpoints as no server will be included in your output folder. If you need server functionality, use `nuxt build` instead.
@@ -104,14 +106,14 @@ If you prerender your app with the `nuxt generate` or `nuxt build --prerender` c
 
 If you are using purely client-side rendering, then this might be unnecessary. You might only need a single `index.html` file, plus `200.html` and `404.html` fallbacks, which you can tell your static web host to serve up for all requests.
 
-In order to achieve this we can change how the routes are prerendered. Just add this to [your hooks](/docs/api/advanced/hooks#nuxt-hooks-build-time) in your `nuxt.config.ts`:
+In order to achieve this we can change how the routes are prerendered. Just add this to [your hooks](/docs/4.x/api/advanced/hooks#nuxt-hooks-build-time) in your `nuxt.config.ts`:
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   hooks: {
     'prerender:routes' ({ routes }) {
       routes.clear() // Do not generate any routes (except the defaults)
-    }
+    },
   },
 })
 ```
@@ -126,21 +128,21 @@ The `200.html` and `404.html` might be useful for the hosting provider you are u
 
 #### Skipping Client Fallback Generation
 
-When prerendering a client-rendered app, Nuxt will generate `index.html`, `200.html` and `404.html` files by default. However, if you need to prevent any (or all) of these files from being generated in your build, you can use the `'prerender:generate'` hook from [Nitro](/docs/getting-started/prerendering#prerendergenerate-nitro-hook).
+When prerendering a client-rendered app, Nuxt will generate `index.html`, `200.html` and `404.html` files by default. However, if you need to prevent any (or all) of these files from being generated in your build, you can use the `'prerender:generate'` hook from [Nitro](/docs/4.x/getting-started/prerendering#prerendergenerate-nitro-hook).
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   ssr: false,
   nitro: {
     hooks: {
-      'prerender:generate'(route) {
+      'prerender:generate' (route) {
         const routesToSkip = ['/index.html', '/200.html', '/404.html']
         if (routesToSkip.includes(route.route)) {
           route.skip = true
         }
-      }
-    }
-  }
+      },
+    },
+  },
 })
 ```
 
@@ -172,8 +174,8 @@ export default defineNuxtConfig({
     // Add cors headers on API routes
     '/api/**': { cors: true },
     // Redirects legacy urls
-    '/old-page': { redirect: '/new-page' }
-  }
+    '/old-page': { redirect: '/new-page' },
+  },
 })
 ```
 
@@ -193,7 +195,7 @@ The different properties you can use are the following:
 Whenever possible, route rules will be automatically applied to the deployment platform's native rules for optimal performances (Netlify and Vercel are currently supported).
 
 ::important
-Note that Hybrid Rendering is not available when using [`nuxt generate`](/docs/api/commands/generate).
+Note that Hybrid Rendering is not available when using [`nuxt generate`](/docs/4.x/api/commands/generate).
 ::
 
 **Examples:**
@@ -219,7 +221,7 @@ With ESR, the rendering process is pushed to the 'edge' of the network - the CDN
 
 When a request for a page is made, instead of going all the way to the original server, it's intercepted by the nearest edge server. This server generates the HTML for the page and sends it back to the user. This process minimizes the physical distance the data has to travel, **reducing latency and loading the page faster**.
 
-Edge-side rendering is possible thanks to [Nitro](https://nitro.build/), the [server engine](/docs/guide/concepts/server-engine) that powers Nuxt. It offers cross-platform support for Node.js, Deno, Cloudflare Workers, and more.
+Edge-side rendering is possible thanks to [Nitro](https://nitro.build/), the [server engine](/docs/4.x/guide/concepts/server-engine) that powers Nuxt. It offers cross-platform support for Node.js, Deno, Cloudflare Workers, and more.
 
 The current platforms where you can leverage ESR are:
 - [Cloudflare Pages](https://pages.cloudflare.com) with zero configuration using the git integration and the `nuxt build` command

package/2.guide/{1.concepts → 2.concepts}/4.server-engine.md

@@ -16,7 +16,7 @@ It is shipped with many features:
 
 ## API Layer
 
-Server [API endpoints](/docs/guide/directory-structure/server#api-routes) and [Middleware](/docs/guide/directory-structure/server#server-middleware) are added by Nitro that internally uses [h3](https://github.com/h3js/h3).
+Server [API endpoints](/docs/4.x/guide/directory-structure/server#server-routes) and [Middleware](/docs/4.x/guide/directory-structure/server#server-middleware) are added by Nitro that internally uses [h3](https://github.com/h3js/h3).
 
 Key features include:
 
@@ -26,15 +26,15 @@ Key features include:
 
 Check out [the h3 docs](https://github.com/h3js/h3) for more information.
 
-::read-more{to="/docs/guide/directory-structure/server#server-routes"}
+::read-more{to="/docs/4.x/guide/directory-structure/server#server-routes"}
 Learn more about the API layer in the `server/` directory.
 ::
 
 ## Direct API Calls
 
-Nitro allows 'direct' calling of routes via the globally-available [`$fetch`](/docs/api/utils/dollarfetch) helper. This will make an API call to the server if run on the browser, but will directly call the relevant function if run on the server, **saving an additional API call**.
+Nitro allows 'direct' calling of routes via the globally-available [`$fetch`](/docs/4.x/api/utils/dollarfetch) helper. This will make an API call to the server if run on the browser, but will directly call the relevant function if run on the server, **saving an additional API call**.
 
-[`$fetch`](/docs/api/utils/dollarfetch) API is using [ofetch](https://github.com/unjs/ofetch), with key features including:
+[`$fetch`](/docs/4.x/api/utils/dollarfetch) API is using [ofetch](https://github.com/unjs/ofetch), with key features including:
 
 - Automatic parsing of JSON responses (with access to raw response if needed)
 - Request body and params are automatically handled, with correct `Content-Type` headers
@@ -45,7 +45,7 @@ For more information on `$fetch` features, check out [ofetch](https://github.com
 
 When using API routes (or middleware), Nitro will generate typings for these routes as long as you are returning a value instead of using `res.end()` to send a response.
 
-You can access these types when using [`$fetch()`](/docs/api/utils/dollarfetch) or [`useFetch()`](/docs/api/composables/use-fetch).
+You can access these types when using [`$fetch()`](/docs/4.x/api/utils/dollarfetch) or [`useFetch()`](/docs/4.x/api/composables/use-fetch).
 
 ## Standalone Server
 
@@ -53,7 +53,7 @@ Nitro produces a standalone server dist that is independent of `node_modules`.
 
 The server in Nuxt 2 is not standalone and requires part of Nuxt core to be involved by running `nuxt start` (with the [`nuxt-start`](https://www.npmjs.com/package/nuxt-start) or [`nuxt`](https://www.npmjs.com/package/nuxt) distributions) or custom programmatic usage, which is fragile and prone to breakage and not suitable for serverless and service worker environments.
 
-Nuxt generates this dist when running `nuxt build` into a [`.output`](/docs/guide/directory-structure/output) directory.
+Nuxt generates this dist when running `nuxt build` into a [`.output`](/docs/4.x/guide/directory-structure/output) directory.
 
 The output contains runtime code to run your Nuxt server in any environment (including experimental browser service workers!) and serve your static files, making it a true hybrid framework for the JAMstack. In addition, Nuxt implements a native storage layer, supporting multi-source drivers and local assets.
 

package/2.guide/{1.concepts → 2.concepts}/5.modules.md

@@ -7,7 +7,7 @@ description: "Nuxt provides a module system to extend the framework core and sim
 
 When developing production-grade applications with Nuxt you might find that the framework's core functionality is not enough. Nuxt can be extended with configuration options and plugins, but maintaining these customizations across multiple projects can be tedious, repetitive and time-consuming. On the other hand, supporting every project's needs out of the box would make Nuxt very complex and hard to use.
 
-This is one of the reasons why Nuxt provides a module system that makes it possible to extend the core. Nuxt modules are async functions that sequentially run when starting Nuxt in development mode using [`nuxt dev`](/docs/api/commands/dev) or building a project for production with [`nuxt build`](/docs/api/commands/build). They can override templates, configure webpack loaders, add CSS libraries, and perform many other useful tasks.
+This is one of the reasons why Nuxt provides a module system that makes it possible to extend the core. Nuxt modules are async functions that sequentially run when starting Nuxt in development mode using [`nuxt dev`](/docs/4.x/api/commands/dev) or building a project for production with [`nuxt build`](/docs/4.x/api/commands/build). They can override templates, configure webpack loaders, add CSS libraries, and perform many other useful tasks.
 
 Best of all, Nuxt modules can be distributed in npm packages. This makes it possible for them to be reused across projects and shared with the community, helping create an ecosystem of high-quality add-ons.
 
@@ -17,7 +17,7 @@ Explore Nuxt Modules
 
 ## Add Nuxt Modules
 
-Once you have installed the modules you can add them to your [`nuxt.config.ts`](/docs/guide/directory-structure/nuxt-config) file under the `modules` property. Module developers usually provide additional steps and details for usage.
+Once you have installed the modules you can add them to your [`nuxt.config.ts`](/docs/4.x/guide/directory-structure/nuxt-config) file under the `modules` property. Module developers usually provide additional steps and details for usage.
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
@@ -32,8 +32,8 @@ export default defineNuxtConfig({
     ['./modules/example', { token: '123' }],
 
     // Inline module definition
-    async (inlineOptions, nuxt) => { }
-  ]
+    async (inlineOptions, nuxt) => { },
+  ],
 })
 ```
 
@@ -45,4 +45,4 @@ Nuxt modules are now build-time-only, and the `buildModules` property used in Nu
 
 Everyone has the opportunity to develop modules and we cannot wait to see what you will build.
 
-:read-more{to="/docs/guide/going-further/modules" title="Module Author Guide"}
+:read-more{to="/docs/4.x/guide/going-further/modules" title="Module Author Guide"}

package/2.guide/{1.concepts → 2.concepts}/7.esm.md

@@ -32,7 +32,7 @@ export { a }
 
 Before ECMAScript Modules (ESM) became a standard (it took more than 10 years!), tooling like
 [webpack](https://webpack.js.org/guides/ecma-script-modules) and even languages like TypeScript started supporting so-called **ESM syntax**.
-However, there are some key differences with actual spec; here's [a helpful explainer](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive).
+However, there are some key differences with actual spec; here's [a helpful explainer](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/).
 
 ### What is 'Native' ESM?
 
@@ -111,7 +111,7 @@ const { named } = pkg;
 
 ## Troubleshooting ESM Issues
 
-If you encounter these errors, the issue is almost certainly with the upstream library. They need to [fix their library](#library-author-guide) to support being imported by Node.
+If you encounter these errors, the issue is almost certainly with the upstream library. They need to [fix their library](/docs/4.x/guide/concepts/esm#library-author-guide) to support being imported by Node.
 
 ### Transpiling Libraries
 
@@ -120,8 +120,8 @@ In the meantime, you can tell Nuxt not to try to import these libraries by addin
 ```ts twoslash
 export default defineNuxtConfig({
   build: {
-    transpile: ['sample-library']
-  }
+    transpile: ['sample-library'],
+  },
 })
 ```
 
@@ -134,8 +134,8 @@ In some cases, you may also need to manually alias the library to the CJS versio
 ```ts twoslash
 export default defineNuxtConfig({
   alias: {
-    'sample-library': 'sample-library/dist/sample-library.cjs.js'
-  }
+    'sample-library': 'sample-library/dist/sample-library.cjs.js',
+  },
 })
 ```
 
@@ -182,6 +182,8 @@ import('cjs-pkg').then(console.log) // [Module: null prototype] { default: { tes
 
 In this case, we need to manually interop the default export:
 
+<!-- eslint-disable import/no-named-default -->
+
 ```js
 // Static import
 import { default as pkg } from 'cjs-pkg'
@@ -219,16 +221,16 @@ The initial step from CJS to ESM is updating any usage of `require` to use `impo
 
 ::code-group
 
-```js [Before]
-module.exports = ...
+```ts [Before]
+module.exports = function () { /* ... */ }
 
-exports.hello = ...
+exports.hello = 'world'
 ```
 
-```js [After]
-export default ...
+```ts [After]
+export default function () { /* ... */ }
 
-export const hello = ...
+export const hello = 'world'
 ```
 
 ::
@@ -242,7 +244,7 @@ const myLib = require('my-lib')
 ```js [After]
 import myLib from 'my-lib'
 // or
-const myLib = await import('my-lib').then(lib => lib.default || lib)
+const dynamicMyLib = await import('my-lib').then(lib => lib.default || lib)
 ```
 
 ::
@@ -253,7 +255,7 @@ and should be replaced with `import()` and `import.meta.filename`.
 ::code-group
 
 ```js [Before]
-import { join } from 'path'
+const { join } = require('node:path')
 
 const newDir = join(__dirname, 'new-dir')
 ```
@@ -282,7 +284,7 @@ const someFile = await resolvePath('my-lib', { url: import.meta.url })
 
 ### Best Practices
 
-- Prefer named exports rather than default export. This helps reduce CJS conflicts. (see [Default exports](#default-exports) section)
+- Prefer named exports rather than default export. This helps reduce CJS conflicts. (see [Default exports](/docs/4.x/guide/concepts/esm#default-exports) section)
 
 - Avoid depending on Node.js built-ins and CommonJS or Node.js-only dependencies as much as possible to make your library usable in Browsers and Edge Workers without needing Nitro polyfills.