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

package/3.guide/2.best-practices/performance.md

@@ -12,7 +12,7 @@ Nuxt offers several built-in features that help you optimize performance of your
 
 ### Links
 
-[`<NuxtLink>`](/docs/4.x/api/components/nuxt-link) is a drop-in replacement for both Vue Router's `<RouterLink>` component and HTML's `<a>` tag. It intelligently determines whether the link is internal or external and renders it accordingly with available optimizations (prefetching, default attributes, etc.)
+[`<NuxtLink>`](/docs/api/components/nuxt-link) is a drop-in replacement for both Vue Router's `<RouterLink>` component and HTML's `<a>` tag. It intelligently determines whether the link is internal or external and renders it accordingly with available optimizations (prefetching, default attributes, etc.)
 
 ```html
 <template>
@@ -42,7 +42,7 @@ export default defineNuxtConfig({
 })
 ```
 
-:read-more{title="NuxtLink" to="/docs/4.x/api/components/nuxt-link"}
+:read-more{title="NuxtLink" to="/docs/api/components/nuxt-link"}
 
 ### Hybrid Rendering
 
@@ -71,7 +71,7 @@ export default defineNuxtConfig({
 
 Nuxt server will automatically register corresponding middleware and wrap routes with cache handlers using Nitro caching layer.
 
-:read-more{title="Hybrid rendering" to="/docs/4.x/guide/concepts/rendering#hybrid-rendering"}
+:read-more{title="Hybrid rendering" to="/docs/guide/concepts/rendering#hybrid-rendering"}
 
 ### Lazy Loading Components
 
@@ -93,7 +93,7 @@ const show = ref(false)
 
 By using the Lazy prefix you can delay loading the component code until the right moment, which can be helpful for optimizing your JavaScript bundle size.
 
-:read-more{title="Lazy loading components" to="/docs/4.x/directory-structure/app/components#dynamic-imports"}
+:read-more{title="Lazy loading components" to="/docs/directory-structure/app/components#dynamic-imports"}
 
 ### Lazy Hydration
 
@@ -109,13 +109,17 @@ It is not always necessary to hydrate (or make interactive) all the components o
 
 To optimize your app, you may want to delay the hydration of some components until they're visible, or until the browser is done with more important tasks.
 
-:read-more{title="Lazy hydration" to="/docs/4.x/directory-structure/app/components#delayed-or-lazy-hydration"}
+:read-more{title="Lazy hydration" to="/docs/directory-structure/app/components#delayed-or-lazy-hydration"}
+
+For content and marketing sites that need little or no client-side interactivity, you can go further and combine prerendering, the `noScripts` route rule, [server components](/docs/guide/concepts/server-components) and lazy hydration to ship near-zero JavaScript.
+
+:read-more{title="Mostly-static sites" to="/docs/guide/recipes/mostly-static-sites"}
 
 ### Fetching data
 
-To avoid fetching same data twice (once on the server and once on client) Nuxt provides [`useFetch`](/docs/4.x/api/composables/use-fetch) and [`useAsyncData`](/docs/4.x/api/composables/use-async-data). They ensure that if an API call is made on the server, the data is forwarded to the client in the payload instead of being fetched again.
+To avoid fetching same data twice (once on the server and once on client) Nuxt provides [`useFetch`](/docs/api/composables/use-fetch) and [`useAsyncData`](/docs/api/composables/use-async-data). They ensure that if an API call is made on the server, the data is forwarded to the client in the payload instead of being fetched again.
 
-:read-more{title="Data fetching" to="/docs/4.x/getting-started/data-fetching"}
+:read-more{title="Data fetching" to="/docs/getting-started/data-fetching"}
 
 ## Core Nuxt Modules
 
@@ -129,7 +133,7 @@ In Nuxt we can use [Nuxt Image](https://image.nuxt.com/) module that is a plug-a
 
 :video-accordion{title="Watch the video by LearnVue about Nuxt Image" videoId="_UBff2eqGY0"}
 
-[`<NuxtImg>`](/docs/4.x/api/components/nuxt-img) is a drop-in replacement for the native `<img>` tag that comes with following enhancements:
+[`<NuxtImg>`](/docs/api/components/nuxt-img) is a drop-in replacement for the native `<img>` tag that comes with following enhancements:
 
 * Uses built-in provider to optimize local and remote images
 * Converts `src` to provider optimized URLs with modern formats such as WebP or Avif
@@ -218,7 +222,7 @@ To improve performance, we need to first know how to measure it, starting with m
 
 ### Nuxi Analyze
 
-[This](/docs/4.x/api/commands/analyze) command of `nuxt` allows you to analyze the production bundle of your Nuxt application. It leverages `vite-bundle-visualizer` (similar to `webpack-bundle-analyzer`) to generate a visual representation of your application's bundle, making it easier to identify which components take up the most space.
+[This](/docs/api/commands/analyze) command of `nuxt` allows you to analyze the production bundle of your Nuxt application. It leverages `vite-bundle-visualizer` (similar to `webpack-bundle-analyzer`) to generate a visual representation of your application's bundle, making it easier to identify which components take up the most space.
 
 When you see a large block in the visualization, it often signals an opportunity for optimization—whether by splitting it into smaller parts, implementing lazy loading, or replacing it with a more efficient alternative, especially for third-party libraries.
 

package/3.guide/3.ai/1.mcp.md

@@ -26,27 +26,50 @@ The Nuxt MCP server provides the following tools organized by category:
 
 ### Documentation
 
-- **`list_documentation_pages`**: Lists all available Nuxt documentation pages with their categories and basic information. Supports version filtering (3.x, 4.x, or all)
-- **`get_documentation_page`**: Retrieves documentation page content and details by path
-- **`get_getting_started_guide`**: Gets the getting started guide for a specific Nuxt version
+- **`list-documentation-pages`**: Lists all available Nuxt documentation pages with their categories and basic information. Supports version filtering (3.x, 4.x, 5.x, or all)
+- **`get-documentation-page`**: Retrieves documentation page content and details by path
+- **`get-getting-started-guide`**: Gets the getting started guide for a specific Nuxt version
 
 ### Blog
 
-- **`list_blog_posts`**: Lists all Nuxt blog posts with metadata including dates, categories, and tags
-- **`get_blog_post`**: Retrieves blog post content and details by path
+- **`list-blog-posts`**: Lists all Nuxt blog posts with metadata including dates, categories, and tags
+- **`get-blog-post`**: Retrieves blog post content and details by path
 
 ### Deployment
 
-- **`list_deploy_providers`**: Lists all deployment providers and hosting platforms for Nuxt applications
-- **`get_deploy_provider`**: Retrieves deployment provider details and instructions by path
+- **`list-deploy-providers`**: Lists all deployment providers and hosting platforms for Nuxt applications
+- **`get-deploy-provider`**: Retrieves deployment provider details and instructions by path
+
+### Modules
+
+- **`list-modules`**: Lists all available Nuxt modules with optional filtering and sorting by downloads, stars, or date
+- **`get-module`**: Retrieves complete details about a specific module including README, compatibility, maintainers, and stats
+
+### Changelog
+
+- **`get-changelog`**: Retrieves the latest releases from Nuxt core and official modules
+
+## Limit Available Tools
+
+Set the optional `X-MCP-Tools` HTTP header to a comma-separated list of tool names to expose only the tools your assistant needs. This reduces the tool context sent to your assistant.
+
+Use the exact kebab-case MCP tool names returned by the server, for example:
+
+```json
+{
+  "X-MCP-Tools": "list-documentation-pages,get-documentation-page"
+}
+```
+
+No header exposes all tools, an empty header exposes no tools, and an unknown tool name returns a configuration error.
 
 ## Prompts
 
 The Nuxt MCP server provides guided prompts for common workflows:
 
-- **`find_documentation_for_topic`**: Find the best Nuxt documentation for a specific topic or feature
-- **`deployment_guide`**: Get deployment instructions for a specific hosting provider
-- **`migration_help`**: Get help with migrating between Nuxt versions
+- **`find-documentation-for-topic`**: Find the best Nuxt documentation for a specific topic or feature
+- **`deployment-guide`**: Get deployment instructions for a specific hosting provider
+- **`migration-help`**: Get help with migrating between Nuxt versions
 
 You're able to access these resources with tools like Claude Code by using `/`.
 
@@ -85,7 +108,7 @@ The Nuxt connector will appear in the composer's "Developer mode" tool later dur
 Add the server using the CLI command:
 
 ```bash
-claude mcp add --transport http nuxt-remote https://nuxt.com/mcp
+claude mcp add --transport http nuxt https://nuxt.com/mcp
 ```
 
 ### Claude Desktop
@@ -141,13 +164,30 @@ Or manually create/update `.cursor/mcp.json` in your project root:
 }
 ```
 
+### Gemini CLI
+
+1. Locate your Gemini CLI configuration file (usually `~/.gemini/settings.json` or as specified in your environment).
+2. Add the following configuration to your `mcpServers` object:
+
+```json [~/.gemini/settings.json]
+{
+  "mcpServers": {
+    "nuxt": {
+      "httpUrl": "https://nuxt.com/mcp"
+    }
+  }
+}
+```
+
+1. Restart your terminal session or reload the CLI. The Nuxt MCP server tools will now be available for use.
+
 ### Le Chat Mistral
 
 1. Navigate to "Intelligence" > "Connectors"
 2. Click on "Add Connector" button, then select "Custom MCP Connector"
 3. Create your Custom MCP Connector:
-    - Connector Name : `Nuxt`
-    - Connector Server : `https://nuxt.com/mcp`
+    - Connector Name: `Nuxt`
+    - Server URL: `https://nuxt.com/mcp`
 
 ### Visual Studio Code
 
@@ -207,6 +247,55 @@ To verify the MCP server is configured correctly:
 
 For more information on using MCP with GitHub Copilot coding agent, see [Extend coding agent with MCP](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/extend-coding-agent-with-mcp).
 
+### GitHub Copilot CLI
+
+1. Start GitHub Copilot CLI in interactive mode.
+2. Run `/mcp add`.
+3. Fill in the configuration form with:
+   - **Server Name**: `nuxt`
+   - **Server Type**: `HTTP`
+   - **URL**: `https://nuxt.com/mcp`
+   - **HTTP Headers**: leave empty
+   - **Tools**: `*`
+4. Press <kbd>Ctrl</kbd>+<kbd>S</kbd> to save. The MCP server is available immediately without restarting the CLI.
+
+Or add the server directly to `~/.copilot/mcp-config.json`:
+
+```json [~/.copilot/mcp-config.json]
+{
+  "mcpServers": {
+    "nuxt": {
+      "type": "http",
+      "url": "https://nuxt.com/mcp",
+      "tools": ["*"]
+    }
+  }
+}
+```
+
+Use `/mcp show` to confirm the server is configured and available.
+
+For more details, see [Adding MCP servers for GitHub Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers).
+
+### Google Antigravity
+
+1. Open the MCP store via the "..." dropdown at the top of the editor's agent panel.
+2. Click on "Manage MCP Servers"
+3. Click on "View raw config"
+4. Modify the `mcp_config.json` with your custom MCP server configuration:
+
+```json [mcp_config.json]
+{
+  "mcpServers": {
+    "nuxt": {
+      "serverUrl": "https://nuxt.com/mcp"
+    }
+  }
+}
+```
+
+1. Return to the "Manage MCP Servers" tab and click "Refresh". The Nuxt MCP server should now appear.
+
 ### Windsurf
 
 1. Open Windsurf and navigate to "Settings" > "Windsurf Settings" > "Cascade"
@@ -217,8 +306,7 @@ For more information on using MCP with GitHub Copilot coding agent, see [Extend
 {
   "mcpServers": {
     "nuxt": {
-      "type": "http",
-      "url": "https://nuxt.com/mcp"
+      "serverUrl": "https://nuxt.com/mcp"
     }
   }
 }
@@ -234,10 +322,7 @@ For more information on using MCP with GitHub Copilot coding agent, see [Extend
 {
   "context_servers": {
     "nuxt": {
-      "source": "custom",
-      "command": "npx",
-      "args": ["mcp-remote", "https://nuxt.com/mcp"],
-      "env": {}
+      "url": "https://nuxt.com/mcp"
     }
   }
 }

package/3.guide/4.modules/2.module-anatomy.md

@@ -6,7 +6,7 @@ description: "Learn how Nuxt modules are structured and how to define them."
 There are two types of Nuxt modules:
 
 - published modules are distributed on npm - you can see a list of some community modules on [the Nuxt website](/modules).
-- "local" modules exist within a Nuxt project, either [inlined in Nuxt config](/docs/4.x/api/nuxt-config#modules) or within [the `modules` directory](/docs/4.x/directory-structure/modules).
+- "local" modules exist within a Nuxt project, either [inlined in Nuxt config](/docs/api/nuxt-config#modules) or within [the `modules` directory](/docs/directory-structure/modules).
 
 In either case, they work in the same way.
 
@@ -31,7 +31,7 @@ export default function (inlineOptions, nuxt) {
 }
 ```
 
-You can get type hinting for this function using the higher-level `defineNuxtModule` helper provided by [Nuxt Kit](/docs/4.x/guide/going-further/kit).
+You can get type hinting for this function using the higher-level `defineNuxtModule` helper provided by [Nuxt Kit](/docs/guide/going-further/kit).
 
 ```ts
 import { defineNuxtModule } from '@nuxt/kit'
@@ -112,9 +112,9 @@ Modules, like everything in a Nuxt configuration, aren't included in your applic
 Inside the runtime directory, you can provide any kind of assets related to the Nuxt app:
 - Vue components
 - Composables
-- [Nuxt plugins](/docs/4.x/directory-structure/app/plugins)
+- [Nuxt plugins](/docs/directory-structure/app/plugins)
 
-To the [server engine](/docs/4.x/guide/concepts/server-engine), Nitro:
+To the [server engine](/docs/guide/concepts/server-engine), Nitro:
 - API routes
 - Middlewares
 - Nitro plugins
@@ -128,7 +128,7 @@ Or any other kind of asset you want to inject in users' Nuxt applications:
 You'll then be able to inject all those assets inside the application from your [module definition](#define-your-module).
 
 ::tip
-Learn more about asset injection in [the recipes section](/docs/4.x/guide/modules/recipes-basics).
+Learn more about asset injection in [the recipes section](/docs/guide/modules/recipes-basics).
 ::
 
 ::warning

package/3.guide/4.modules/3.recipes-basics.md

@@ -29,7 +29,7 @@ Watch Vue School video about altering Nuxt configuration.
 
 ## Expose Options to Runtime
 
-Because modules aren't part of the application runtime, their options aren't either. However, in many cases, you might need access to some of these module options within your runtime code. We recommend exposing the needed config using Nuxt's [`runtimeConfig`](/docs/4.x/api/nuxt-config#runtimeconfig).
+Because modules aren't part of the application runtime, their options aren't either. However, in many cases, you might need access to some of these module options within your runtime code. We recommend exposing the needed config using Nuxt's [`runtimeConfig`](/docs/api/nuxt-config#runtimeconfig).
 
 <!-- TODO: Update after #18466 (or equivalent) -->
 
@@ -60,7 +60,7 @@ const options = useRuntimeConfig().public.myModule
 Be careful not to expose any sensitive module configuration on the public runtime config, such as private API keys, as they will end up in the public bundle.
 ::
 
-:read-more{to="/docs/4.x/guide/going-further/runtime-config"}
+:read-more{to="/docs/guide/going-further/runtime-config"}
 
 ::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/passing-and-exposing-module-options?friend=nuxt" target="_blank"}
 Watch Vue School video about passing and exposing Nuxt module options.
@@ -83,7 +83,7 @@ export default defineNuxtModule({
 })
 ```
 
-:read-more{to="/docs/4.x/guide/going-further/kit"}
+:read-more{to="/docs/guide/going-further/kit"}
 
 ## Add Components
 
@@ -132,7 +132,7 @@ export default defineNuxtModule({
 ::tip{icon="i-lucide-lightbulb"}
 It is highly recommended to prefix your exports to avoid conflicts with user code or other modules.
 
-:read-more{to="/docs/4.x/guide/modules/best-practices#prefix-your-exports"}
+:read-more{to="/docs/guide/modules/best-practices#prefix-your-exports"}
 ::
 
 ::note
@@ -193,7 +193,7 @@ export default defineNuxtModule({
 ::tip{icon="i-lucide-lightbulb"}
 It is highly recommended to prefix your exports to avoid conflicts with user code or other modules.
 
-:read-more{to="/docs/4.x/guide/modules/best-practices#prefix-your-exports"}
+:read-more{to="/docs/guide/modules/best-practices#prefix-your-exports"}
 ::
 
 ::note
@@ -352,7 +352,7 @@ export default defineNuxtModule({
 ::tip{icon="i-lucide-lightbulb"}
 It is highly recommended to prefix your server routes to avoid conflicts with user-defined routes. Common paths like `/api/auth`, `/api/login`, or `/api/user` may already be used by the application.
 
-:read-more{to="/docs/4.x/guide/modules/best-practices#prefix-your-exports"}
+:read-more{to="/docs/guide/modules/best-practices#prefix-your-exports"}
 ::
 
 ## Add Other Assets
@@ -371,7 +371,7 @@ export default defineNuxtModule({
 })
 ```
 
-And a more advanced one, exposing a folder of assets through [Nitro](/docs/4.x/guide/concepts/server-engine)'s `publicAssets` option:
+And a more advanced one, exposing a folder of assets through [Nitro](/docs/guide/concepts/server-engine)'s `publicAssets` option:
 
 ```js
 import { createResolver, defineNuxtModule } from '@nuxt/kit'
@@ -408,4 +408,4 @@ export default defineNuxtModule({
 })
 ```
 
-:read-more{to="/docs/4.x/guide/modules/module-dependencies"}
+:read-more{to="/docs/guide/modules/module-dependencies"}

package/3.guide/4.modules/4.module-dependencies.md

@@ -54,7 +54,7 @@ The key of each entry identifies the module to depend on. You can use an npm pac
 
 ## Depending on Local Modules
 
-When the dependency lives inside  the [`modules/` directory](/docs/4.x/guide/directory-structure/modules), use a file path to declare the dependency:
+When the dependency lives inside  the [`modules/` directory](/docs/guide/directory-structure/modules), use a file path to declare the dependency:
 
 ```ts
 import { defineNuxtModule } from '@nuxt/kit'

package/3.guide/4.modules/5.recipes-advanced.md

@@ -7,7 +7,7 @@ Here are some advanced patterns for authoring modules, including hooks, template
 
 ## Use Lifecycle Hooks
 
-[Lifecycle hooks](/docs/4.x/guide/going-further/hooks) allow you to expand almost every aspect of Nuxt. Modules can hook to them programmatically or through the `hooks` map in their definition.
+[Lifecycle hooks](/docs/guide/going-further/hooks) allow you to expand almost every aspect of Nuxt. Modules can hook to them programmatically or through the `hooks` map in their definition.
 
 ```js
 import { addPlugin, createResolver, defineNuxtModule } from '@nuxt/kit'
@@ -28,7 +28,7 @@ export default defineNuxtModule({
 })
 ```
 
-:read-more{to="/docs/4.x/api/advanced/hooks"}
+:read-more{to="/docs/api/advanced/hooks"}
 
 ::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/nuxt-lifecycle-hooks?friend=nuxt" target="_blank"}
 Watch Vue School video about using Nuxt lifecycle hooks in modules.
@@ -184,10 +184,8 @@ nuxt.options.typescript.nodeTsConfig.include ??= []
 nuxt.options.typescript.nodeTsConfig.include.push(resolve('./augments.d.ts'))
 
 // extend tsconfig.server.json
-nuxt.options.nitro.typescript ??= {}
-nuxt.options.nitro.typescript.tsConfig ??= {}
-nuxt.options.nitro.typescript.tsConfig.include ??= []
-nuxt.options.nitro.typescript.tsConfig.include.push(resolve('./augments.d.ts'))
+nuxt.options.typescript.serverTsConfig.include ??= []
+nuxt.options.typescript.serverTsConfig.include.push(resolve('./augments.d.ts'))
 ```
 
 Alternatively, you can use the `prepare:types` and `nitro:prepare:types` hooks to extend the TypeScript references for specific type contexts, or modify the TypeScript configuration similar to the example above.
@@ -236,8 +234,8 @@ Nuxt automatically includes your module's directories in the appropriate type co
 
 Server routes are also type-checked using `tsconfig.app.json` in addition to `tsconfig.server.json`.
 
-This is required because Nuxt infers the return types of your server endpoints to provide response types in [`$fetch`](/docs/4.x/api/utils/dollarfetch) and [`useFetch`](/docs/4.x/api/composables/use-fetch).
+This is required because Nuxt infers the return types of your server endpoints to provide response types in [`$fetch`](/docs/api/utils/dollarfetch) and [`useFetch`](/docs/api/composables/use-fetch).
 
 ::warning
-This can cause issues when using **server-only types** in your route files. For example, if a module creates a server-only virtual file using [`addServerTemplate`](/docs/4.x/api/kit/templates#addservertemplate) and you declare types for it in `tsconfig.server.json`, those type declarations will only be available in the server context. When the app context type-checks your server routes, it won't recognize these server-only types and will report errors.  To resolve this, you unfortunately need to declare such types in the app context as well.
+This can cause issues when using **server-only types** in your route files. For example, if a module creates a server-only virtual file using [`addServerTemplate`](/docs/api/kit/templates#addservertemplate) and you declare types for it in `tsconfig.server.json`, those type declarations will only be available in the server context. When the app context type-checks your server routes, it won't recognize these server-only types and will report errors.  To resolve this, you unfortunately need to declare such types in the app context as well.
 ::

package/3.guide/4.modules/6.testing.md

@@ -15,7 +15,7 @@ We're still discussing and exploring how to ease unit and integration testing on
 
 ## Write E2E Tests
 
-[Nuxt Test Utils](/docs/4.x/getting-started/testing) is the go-to library to help you test your module in an end-to-end way. Here's the workflow to adopt with it:
+[Nuxt Test Utils](/docs/getting-started/testing) is the go-to library to help you test your module in an end-to-end way. Here's the workflow to adopt with it:
 
 1. Create a Nuxt application to be used as a "fixture" inside `test/fixtures/*`
 2. Setup Nuxt with this fixture inside your test file
@@ -69,7 +69,7 @@ An example of such a workflow is available on [the module starter](https://githu
 
 ## Test Manually
 
-Having a playground Nuxt application to test your module when developing it is really useful. [The module starter integrates one for that purpose](/docs/4.x/guide/modules/getting-started#develop-your-module).
+Having a playground Nuxt application to test your module when developing it is really useful. [The module starter integrates one for that purpose](/docs/guide/modules/getting-started#develop-your-module).
 
 You can test your module with other Nuxt applications (applications that are not part of your module repository) locally. To do so, you can use [`npm pack`](https://docs.npmjs.com/cli/commands/npm-pack/) command, or your package manager equivalent, to create a tarball from your module. Then in your test project, you can add your module to `package.json` packages as: `"my-module": "file:/path/to/tarball.tgz"`.
 

package/3.guide/4.modules/7.best-practices.md

@@ -65,7 +65,7 @@ export default defineNuxtModule({
 })
 ```
 
-This pattern prevents unnecessary work on every build and provides a better developer experience. See the [lifecycle hooks documentation](/docs/4.x/api/kit/modules#using-lifecycle-hooks-for-module-installation-and-upgrade) for more details.
+This pattern prevents unnecessary work on every build and provides a better developer experience. See the [lifecycle hooks documentation](/docs/api/kit/modules#using-lifecycle-hooks-for-module-installation-and-upgrade) for more details.
 
 ## Be TypeScript Friendly
 
@@ -75,7 +75,7 @@ Exposing types and using TypeScript to develop modules benefits users even when
 
 ## Use ESM Syntax
 
-Nuxt relies on native ESM. Please read [Native ES Modules](/docs/4.x/guide/concepts/esm) for more information.
+Nuxt relies on native ESM. Please read [Native ES Modules](/docs/guide/concepts/esm) for more information.
 
 ## Document Your Module