@nuxt/docs-nightly 4.5.1-29752449.30d24817 → 4.5.2-2610052030-052d82e

package/2.directory-structure/index.md

@@ -13,53 +13,57 @@ The root directory of a Nuxt application is the directory that contains the `nux
 ## App Directory
 
 The `app/` directory is the main directory of the Nuxt application. It contains the following subdirectories:
-- [`assets/`](/docs/4.x/directory-structure/app/assets): website's assets that the build tool (Vite or webpack) will process
-- [`components/`](/docs/4.x/directory-structure/app/components): Vue components of the application
-- [`composables/`](/docs/4.x/directory-structure/app/composables): add your Vue composables
-- [`layouts/`](/docs/4.x/directory-structure/app/layouts): Vue components that wrap around your pages and avoid re-rendering between pages
-- [`middleware/`](/docs/4.x/directory-structure/app/middleware): run code before navigating to a particular route
-- [`pages/`](/docs/4.x/directory-structure/app/pages): file-based routing to create routes within your web application
-- [`plugins/`](/docs/4.x/directory-structure/app/plugins): use Vue plugins and more at the creation of your Nuxt application
-- [`utils/`](/docs/4.x/directory-structure/app/utils): add functions throughout your application that can be used in your components, composables, and pages.
+- [`assets/`](/docs/directory-structure/app/assets): website's assets that the build tool (Vite or webpack) will process
+- [`components/`](/docs/directory-structure/app/components): Vue components of the application
+- [`composables/`](/docs/directory-structure/app/composables): add your Vue composables
+- [`layouts/`](/docs/directory-structure/app/layouts): Vue components that wrap around your pages and avoid re-rendering between pages
+- [`middleware/`](/docs/directory-structure/app/middleware): run code before navigating to a particular route
+- [`pages/`](/docs/directory-structure/app/pages): file-based routing to create routes within your web application
+- [`plugins/`](/docs/directory-structure/app/plugins): use Vue plugins and more at the creation of your Nuxt application
+- [`utils/`](/docs/directory-structure/app/utils): add functions throughout your application that can be used in your components, composables, and pages.
 
 This directory also includes specific files:
-- [`app.config.ts`](/docs/4.x/directory-structure/app/app-config): a reactive configuration within your application
-- [`app.vue`](/docs/4.x/directory-structure/app/app): the root component of your Nuxt application
-- [`error.vue`](/docs/4.x/directory-structure/app/error): the error page of your Nuxt application
+- [`app.config.ts`](/docs/directory-structure/app/app-config): a reactive configuration within your application
+- [`app.vue`](/docs/directory-structure/app/app): the root component of your Nuxt application
+- [`error.vue`](/docs/directory-structure/app/error): the error page of your Nuxt application
 
 ## Public Directory
 
-The [`public/`](/docs/4.x/directory-structure/public) directory is the directory that contains the public files of the Nuxt application. Files contained within this directory are served at the root and are not modified by the build process.
+The [`public/`](/docs/directory-structure/public) directory is the directory that contains the public files of the Nuxt application. Files contained within this directory are served at the root and are not modified by the build process.
 
 This is suitable for files that have to keep their names (e.g. `robots.txt`) _or_ likely won't change (e.g. `favicon.ico`).
 
 ## Server Directory
 
-The [`server/`](/docs/4.x/directory-structure/server) directory is the directory that contains the server-side code of the Nuxt application. It contains the following subdirectories:
-- [`api/`](/docs/4.x/directory-structure/server#server-routes): contains the API routes of the application.
-- [`routes/`](/docs/4.x/directory-structure/server#server-routes): contains the server routes of the application (e.g. dynamic `/sitemap.xml`).
-- [`middleware/`](/docs/4.x/directory-structure/server#server-middleware): run code before a server route is processed
-- [`plugins/`](/docs/4.x/directory-structure/server#server-plugins): use plugins and more at the creation of the Nuxt server
-- [`utils/`](/docs/4.x/directory-structure/server#server-utilities): add functions throughout your application that can be used in your server  code.
+The [`server/`](/docs/directory-structure/server) directory is the directory that contains the server-side code of the Nuxt application. It contains the following subdirectories:
+- [`api/`](/docs/directory-structure/server#server-routes): contains the API routes of the application.
+- [`routes/`](/docs/directory-structure/server#server-routes): contains the server routes of the application (e.g. dynamic `/sitemap.xml`).
+- [`middleware/`](/docs/directory-structure/server#server-middleware): run code before a server route is processed
+- [`plugins/`](/docs/directory-structure/server#server-plugins): use plugins and more at the creation of the Nuxt server
+- [`utils/`](/docs/directory-structure/server#server-utilities): add functions throughout your application that can be used in your server  code.
 
 ## Shared Directory
 
-The [`shared/`](/docs/4.x/directory-structure/shared) directory is the directory that contains the shared code of the Nuxt application and Nuxt server. This code can be used in both the Vue app and the Nitro server.
+The [`shared/`](/docs/directory-structure/shared) directory is the directory that contains the shared code of the Nuxt application and Nuxt server. This code can be used in both the Vue app and the Nitro server.
+
+## Test Directory
+
+The [`test/`](/docs/directory-structure/test) directory is the recommended place for application tests (unit, Nuxt runtime, and end-to-end). See [Organizing Your Tests](/docs/getting-started/testing#organizing-your-tests) for layout and setup details.
 
 ## Content Directory
 
-The [`content/`](/docs/4.x/directory-structure/content) directory is enabled by the [Nuxt Content](https://content.nuxt.com) module. It is used to create a file-based CMS for your application using Markdown files.
+The [`content/`](/docs/directory-structure/content) directory is enabled by the [Nuxt Content](https://content.nuxt.com) module. It is used to create a file-based CMS for your application using Markdown files.
 
 ## Modules Directory
 
-The [`modules/`](/docs/4.x/directory-structure/modules) directory is the directory that contains the local modules of the Nuxt application. Modules are used to extend the functionality of the Nuxt application.
+The [`modules/`](/docs/directory-structure/modules) directory is the directory that contains the local modules of the Nuxt application. Modules are used to extend the functionality of the Nuxt application.
 
 ## Layers Directory
 
-The [`layers/`](/docs/4.x/directory-structure/layers) directory allows you to organize and share reusable code, components, composables, and configurations. Layers within this directory are automatically registered in your project.
+The [`layers/`](/docs/directory-structure/layers) directory allows you to organize and share reusable code, components, composables, and configurations. Layers within this directory are automatically registered in your project.
 
 ## Nuxt Files
 
-- [`nuxt.config.ts`](/docs/4.x/directory-structure/nuxt-config) file is the main configuration file for the Nuxt application.
-- [`.nuxtrc`](/docs/4.x/directory-structure/nuxtrc) file is another syntax for configuring the Nuxt application (useful for global configurations).
-- [`.nuxtignore`](/docs/4.x/directory-structure/nuxtignore) file is used to ignore files in the root directory during the build phase.
+- [`nuxt.config.ts`](/docs/directory-structure/nuxt-config) file is the main configuration file for the Nuxt application.
+- [`.nuxtrc`](/docs/directory-structure/nuxtrc) file is another syntax for configuring the Nuxt application (useful for global configurations).
+- [`.nuxtignore`](/docs/directory-structure/nuxtignore) file is used to ignore files in the root directory during the build phase.

package/3.guide/0.index.md

@@ -7,22 +7,22 @@ surround: false
 ---
 
 ::card-group{class="sm:grid-cols-1"}
-  ::card{icon="i-lucide-medal" title="Key Concepts" to="/docs/4.x/guide/concepts"}
+  ::card{icon="i-lucide-medal" title="Key Concepts" to="/docs/guide/concepts"}
   Discover the main concepts behind Nuxt, from auto-import, hybrid rendering to its TypeScript support.
   ::
-  ::card{icon="i-lucide-square-check" title="Best Practices" to="/docs/4.x/guide/best-practices"}
+  ::card{icon="i-lucide-square-check" title="Best Practices" to="/docs/guide/best-practices"}
   Learn about best practices when developing with Nuxt.
   ::
-  ::card{icon="i-lucide-bot" title="Working with AI" to="/docs/4.x/guide/ai"}
+  ::card{icon="i-lucide-bot" title="Working with AI" to="/docs/guide/ai"}
   Integrate AI tools into your Nuxt workflow with MCP Server and LLMs.txt.
   ::
-  ::card{icon="i-lucide-box" title="Module Author Guide" to="/docs/4.x/guide/modules"}
+  ::card{icon="i-lucide-box" title="Module Author Guide" to="/docs/guide/modules"}
   Learn how to create Nuxt modules to integrate, enhance or extend any Nuxt application.
   ::
-  ::card{icon="i-lucide-book-open" title="Recipes" to="/docs/4.x/guide/recipes"}
+  ::card{icon="i-lucide-book-open" title="Recipes" to="/docs/guide/recipes"}
   Find solutions to common problems and learn how to implement them in your Nuxt project.
   ::
-  ::card{icon="i-lucide-star" title="Going Further" to="/docs/4.x/guide/going-further"}
+  ::card{icon="i-lucide-star" title="Going Further" to="/docs/guide/going-further"}
   Master Nuxt with advanced concepts like experimental features, hooks, and more.
   ::
 ::

package/3.guide/1.concepts/1.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](/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).
+Nuxt supports different rendering modes, [universal rendering](/docs/guide/concepts/rendering#universal-rendering), [client-side rendering](/docs/guide/concepts/rendering#client-side-rendering) but also offers [hybrid-rendering](/docs/guide/concepts/rendering#hybrid-rendering) and the possibility to render your application on [CDN Edge Servers](/docs/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/4.x/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/api/nuxt-config#ssr).
 
 ## Universal Rendering
 
@@ -44,7 +44,7 @@ const handleClick = () => {
 
 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/4.x/directory-structure/app/middleware) and [pages](/docs/4.x/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/4.x/directory-structure/app/plugins) can be rendered on the server or client or both. [Components](/docs/4.x/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/4.x/directory-structure/app/composables) and [utilities](/docs/4.x/directory-structure/app/utils) are rendered based on the context of their usage.
+[Middlewares](/docs/directory-structure/app/middleware) and [pages](/docs/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/directory-structure/app/plugins) can be rendered on the server or client or both. [Components](/docs/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/directory-structure/app/composables) and [utilities](/docs/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.
@@ -52,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](/docs/4.x/guide/concepts/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/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.**
 
@@ -91,14 +91,14 @@ export default defineNuxtConfig({
 
 ::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/4.x/api/configuration/nuxt-config#spaloadingtemplate"}
+:read-more{title="SPA Loading Template" to="/docs/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/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.
+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.
 
 ::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.
@@ -106,7 +106,7 @@ 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/4.x/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/api/advanced/hooks#nuxt-hooks-build-time) in your `nuxt.config.ts`:
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
@@ -133,9 +133,61 @@ Static hosts need an HTML shell for client-side routes and missing paths. Nuxt e
 
 `nuxt generate` and `nuxt build --prerender` write these into `.output/public/`. A plain `nuxt build` without prerender does not. With hybrid route rules, add the fallbacks with route rules or run a prerender build if you need them. Point your host at the file your provider expects.
 
+#### Server-rendering the Error Page
+
+By default `404.html` is an empty shell, so your `error.vue` (and its layout and data) only appear once the client app has booted. You can prerender it instead:
+
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  experimental: {
+    prerenderErrorPages: true,
+  },
+})
+```
+
+Nuxt then renders `error.vue` at build time with a synthetic 404 error and writes the result to `404.html`, which hydrates in place at whatever URL your host served it from. Pass an array of status codes between 400 and 599 (`[404, 500]`) to emit additional pages, if your host can serve them.
+
+Because a single file is served for every missing path, the error page cannot depend on the request: `useRoute()`, `useRequestURL()` and data fetched with the current path will hold the build-time values in the prerendered HTML and be corrected on hydration. Wrap request-specific markup in [`<ClientOnly>`](/docs/api/components/client-only), and skip request-specific data fetching with `import.meta.prerender`:
+
+```vue [error.vue]
+<script setup lang="ts">
+import type { NuxtError } from '#app'
+
+defineProps<{ error: NuxtError }>()
+
+const route = useRoute()
+
+const { data: suggestions } = await useAsyncData(
+  'error-suggestions',
+  () => $fetch('/api/suggestions', { query: { path: route.path } }),
+  // at build time the path is `/404.html`, so fetch on the client instead
+  { server: !import.meta.prerender },
+)
+</script>
+
+<template>
+  <div>
+    <h1>{{ error.statusCode }}</h1>
+    <ClientOnly>
+      <p>Nothing found at {{ route.path }}</p>
+    </ClientOnly>
+    <ul v-if="suggestions">
+      <li
+        v-for="suggestion in suggestions"
+        :key="suggestion"
+      >
+        {{ suggestion }}
+      </li>
+    </ul>
+  </div>
+</template>
+```
+
+`import.meta.prerender` is only `true` while the page is being generated, so the same `error.vue` still server-renders its data when the app is deployed with a server.
+
 #### 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/4.x/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/getting-started/prerendering#prerendergenerate-nitro-hook).
 
 ```ts twoslash [nuxt.config.ts]
 // @errors: 2353 7006
@@ -197,17 +249,29 @@ The different properties you can use are the following:
 - `swr: number | boolean`{lang=ts} - Add cache headers to the server response and cache it on the server or reverse proxy for a configurable TTL (time to live). The `node-server` preset of Nitro is able to cache the full response. When the TTL expired, the cached response will be sent while the page will be regenerated in the background. If true is used, a `stale-while-revalidate` header is added without a MaxAge.
 - `isr: number | boolean`{lang=ts} - The behavior is the same as `swr` except that we are able to add the response to the CDN cache on platforms that support this (currently Netlify or Vercel). If `true` is used, the content persists until the next deploy inside the CDN.
 - `prerender: boolean`{lang=ts} - Prerenders routes at build time and includes them in your build as static assets
-- `noScripts: boolean`{lang=ts} - Disables rendering of Nuxt scripts and JS resource hints for sections of your site.
+- `noScripts: boolean`{lang=ts} - Disables rendering of Nuxt scripts and JS resource hints for sections of your site. Read more about [`noScripts`](/docs/guide/going-further/features#noscripts).
 - `appMiddleware: string | string[] | Record<string, boolean>`{lang=ts} - Allows you to define middleware that should or should not run for page paths within the Vue app part of your application (that is, not your Nitro routes)
 
 ::note
-Routes using `isr` or `swr` also generate `_payload.json` files alongside HTML. Client-side navigation loads these cached payloads instead of re-fetching data. Read more about [payload extraction](/docs/4.x/getting-started/prerendering#payload-extraction).
+Routes using `isr` or `swr` also generate `_payload.json` files alongside HTML. Client-side navigation loads these cached payloads instead of re-fetching data. Read more about [payload extraction](/docs/getting-started/prerendering#payload-extraction).
 ::
 
+### Server Bundle Size with `ssr: false`
+
+A route covered by `ssr: false` is only ever rendered in the browser, so Nuxt excludes its page component from the server bundle. This applies whenever the rules covering every path that reaches the page can be resolved at build time, including dynamic routes such as `pages/products/[id].vue` under a `/products/**` rule.
+
+A page is kept in the server bundle when any path that reaches it might still be rendered on the server:
+
+- a more specific rule re-enables SSR somewhere below the client-only one (`'/admin/**': { ssr: false }`{lang=ts} with `'/admin/report': { ssr: true }`{lang=ts})
+- the page has an alias, or a child declared with an absolute path, that falls outside the client-only region
+- the page is a parent shell rendering a child that is still server-rendered
+
+This is a build-time optimization only; it does not change what the server sends to the browser.
+
 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/4.x/api/commands/generate).
+Note that Hybrid Rendering is not available when using [`nuxt generate`](/docs/api/commands/generate).
 ::
 
 **Examples:**
@@ -233,7 +297,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/4.x/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/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/3.guide/1.concepts/10.vuejs-development.md

@@ -26,17 +26,82 @@ We chose to build Nuxt on top of Vue for these reasons:
 
 ### Auto-imports
 
-Every Vue component created in the [`app/components/`](/docs/4.x/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/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/4.x/guide/concepts/auto-imports"}
+:read-more{to="/docs/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/4.x/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/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/4.x/getting-started/routing"}
+:read-more{to="/docs/getting-started/routing"}
 
-:link-example{to="/docs/4.x/examples/features/auto-imports"}
+:link-example{to="/docs/examples/features/auto-imports"}
+
+## Vapor Mode
+
+::warning
+Vapor Mode support is experimental and requires Vue 3.6 or newer. The API may change.
+::
+
+[Vapor Mode](https://github.com/vuejs/core/releases/tag/v3.6.0-rc.1#about-vapor-mode) is an alternative compilation strategy introduced in Vue 3.6 that renders components without the Virtual DOM, lowering memory use and improving runtime performance.
+
+Nuxt supports Vapor Mode in **interop mode**: your application is still rendered with the Virtual DOM, and you opt individual components or pages into Vapor by writing them as Vapor single-file components. This lets you adopt Vapor incrementally, and the rest of Nuxt (routing, `useAsyncData`, layouts, and most built-in components) keeps working unchanged.
+
+### Enabling Vapor Mode
+
+Enable the `vue.vapor` option in your Nuxt config:
+
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  vue: {
+    vapor: true,
+  },
+})
+```
+
+This installs Vue's `vaporInteropPlugin`, which lets Vapor and Virtual DOM components render alongside each other. You can then mark any component or page as Vapor by adding the `vapor` attribute to `<script setup>`:
+
+```vue [app/pages/index.vue]
+<script setup vapor lang="ts">
+const count = ref(0)
+</script>
+
+<template>
+  <button @click="count++">
+    count is {{ count }}
+  </button>
+</template>
+```
+
+### Trying it out
+
+Vapor Mode needs a version of Vue that includes both Vapor and its interop fixes. While Vue 3.6 is in pre-release, install a release candidate (or newer) that contains those fixes:
+
+```json [package.json]
+{
+  "dependencies": {
+    "vue": "^3.6.0-rc.2"
+  }
+}
+```
+
+If you enable `vue.vapor` on an older version of Vue, Nuxt warns and disables it.
+
+We recommend trying Vapor Mode in a fresh project rather than adding it to an existing one. You can also explore a working setup in the [Nuxt Vapor demo](https://github.com/danielroe/nuxt-vapor-demo).
+
+### Known limitations
+
+Because Nuxt runs Vapor in interop mode, some patterns that rely on the Virtual DOM behave differently inside Vapor components:
+
+- **Full Vapor apps are not yet supported.** The application root stays Virtual DOM and you opt in per component; we may support a full Vapor app later on.
+- **Template refs** on a Vapor component do not expose `$el`.
+- **Some built-in components inspect their slot content** and cannot read Vapor slot children. `<ClientOnly>` skips its attribute-forwarding fallthrough, and `<NuxtIsland>`, server components, and the head components that read text children (such as `<Title>`, `<Style>` and `<Noscript>`) warn if you pass a Vapor slot. Pass the value directly instead (for example, a string to `<Title>`).
+- **The Options API is not supported** in Vapor components, so `asyncData` and `fetchKey` via `defineNuxtComponent` are unavailable. Use `<script setup>` with `useAsyncData` instead.
+- **Keyed `onPrehydrate`** falls back to the unkeyed form (and warns in development), because there is no component instance to attach the key to.
+- **Nuxt composables called after `await`** in a Vapor `<script setup>` may lose the Nuxt context. Call them before the first `await` where possible.
+
+Most other Nuxt composables and built-in components work unchanged, because they rely on injection rather than on a component instance.
 
 ## Differences with Nuxt 2 / Vue 2
 
@@ -92,13 +157,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) 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/directory-structure/app/composables).
+- Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core) 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/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/4.x/guide/concepts/typescript"}
+::read-more{to="/docs/guide/concepts/typescript"}
 Read the details about TypeScript in Nuxt
 ::

package/3.guide/1.concepts/2.nuxt-lifecycle.md

@@ -14,7 +14,7 @@ On the server, the following steps are executed for every initial request to you
 
 Nuxt is powered by [Nitro](https://nitro.build/), a modern server engine.
 
-When Nitro starts, it initializes and executes the plugins under the [`/server/plugins`](/docs/4.x/directory-structure/server#server-plugins) directory. These plugins can:
+When Nitro starts, it initializes and executes the plugins under the [`/server/plugins`](/docs/directory-structure/server#server-plugins) directory. These plugins can:
 - Capture and handle application-wide errors.
 - Register hooks that execute when Nitro shuts down.
 - Register hooks for request lifecycle events, such as modifying responses.
@@ -23,7 +23,7 @@ When Nitro starts, it initializes and executes the plugins under the [`/server/p
 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/4.x/directory-structure/server#server-plugins"}
+:read-more{to="/docs/directory-structure/server#server-plugins"}
 
 ### Server middleware
 
@@ -33,7 +33,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/4.x/directory-structure/server#server-middleware"}
+:read-more{to="/docs/directory-structure/server#server-middleware"}
 
 ### App plugins
 
@@ -41,13 +41,13 @@ The Vue and Nuxt instances are created first. Afterward, Nuxt executes its app p
 - 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/4.x/directory-structure/app/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/directory-structure/app/plugins).
 
 ::callout{icon="i-lucide-lightbulb"}
-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.
+After this step, Nuxt calls the [`app:created`](/docs/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
 ::
 
-:read-more{to="/docs/4.x/directory-structure/app/plugins"}
+:read-more{to="/docs/directory-structure/app/plugins"}
 
 ### Route validation
 
@@ -56,9 +56,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 `status` and/or `statusText` to terminate the request.
 
-For more information, see the [Route Validation documentation](/docs/4.x/getting-started/routing#route-validation).
+For more information, see the [Route Validation documentation](/docs/getting-started/routing#route-validation).
 
-:read-more{to="/docs/4.x/getting-started/routing#route-validation"}
+:read-more{to="/docs/getting-started/routing#route-validation"}
 
 ### App middleware
 
@@ -71,11 +71,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/4.x/directory-structure/app/middleware).
+For details about each type and examples, see the [Middleware documentation](/docs/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/4.x/directory-structure/app/middleware"}
+:read-more{to="/docs/directory-structure/app/middleware"}
 
 ### Page and components
 
@@ -100,11 +100,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/4.x/api/advanced/hooks#app-hooks-runtime) hook.
+After rendering the Vue application to HTML, Nuxt calls the [`app:rendered`](/docs/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/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.
+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.
 ::
 
 ::
@@ -122,10 +122,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/4.x/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
+After this step, Nuxt calls the [`app:created`](/docs/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
 ::
 
-:read-more{to="/docs/4.x/directory-structure/app/plugins"}
+:read-more{to="/docs/directory-structure/app/plugins"}
 
 ### Route validation
 
@@ -135,20 +135,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/4.x/directory-structure/app/middleware#when-middleware-runs"}
+:read-more{to="/docs/directory-structure/app/middleware#when-middleware-runs"}
 
 ### Mount Vue app and hydrate
 
-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/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/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/4.x/api/advanced/hooks#app-hooks-runtime) hook.
+Before mounting the Vue application, Nuxt calls the [`app:beforeMount`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
 ::
 
 ::callout{icon="i-lucide-lightbulb"}
-After mounting the Vue application, Nuxt calls the [`app:mounted`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
+After mounting the Vue application, Nuxt calls the [`app:mounted`](/docs/api/advanced/hooks#app-hooks-runtime) hook.
 ::
 
 ### Vue lifecycle

package/3.guide/1.concepts/3.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/4.x/directory-structure/app/components), [`app/composables/`](/docs/4.x/directory-structure/app/composables) and [`app/utils/`](/docs/4.x/directory-structure/app/utils).
+Thanks to its opinionated directory structure, Nuxt can auto-import your [`app/components/`](/docs/directory-structure/app/components), [`app/composables/`](/docs/directory-structure/app/composables) and [`app/utils/`](/docs/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/4.x/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/api).
 ::
 
 ::note
-In the [`server`](/docs/4.x/directory-structure/server) directory, Nuxt auto-imports exported functions and variables from `server/utils/`.
+In the [`server`](/docs/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/4.x/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/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/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.
+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.
 
 ```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/4.x/guide/going-further/experimental-features#asynccontext" icon="i-lucide-star"}
+::read-more{to="/docs/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/4.x/directory-structure/app/components).
-- `app/composables/` for [Vue composables](/docs/4.x/directory-structure/app/composables).
+- `app/components/` for [Vue components](/docs/directory-structure/app/components).
+- `app/composables/` for [Vue composables](/docs/directory-structure/app/composables).
 - `app/utils/` for helper functions and other utilities.
 
-:link-example{to="/docs/4.x/examples/features/auto-imports"}
+:link-example{to="/docs/examples/features/auto-imports"}
 
 ::warning
 **Auto-imported `ref` and `computed` won't be unwrapped in a component `<template>`.** :br
@@ -139,7 +139,7 @@ export default defineNuxtConfig({
 })
 ```
 
-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`.
+This will disable auto-imports completely but it's still possible to use [explicit imports](/docs/guide/concepts/auto-imports#explicit-imports) from `#imports`.
 
 ### Partially Disabling Auto-imports
 
@@ -167,7 +167,7 @@ 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/4.x/directory-structure/app/components"}
+:read-more{to="/docs/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).