@nuxt/docs-nightly 4.3.0-29481970.f136022c → 4.3.0-29483992.8d4f9ba5

package/2.directory-structure/1.app/1.layouts.md

@@ -156,10 +156,16 @@ export default defineNuxtConfig({
     '/admin': { appLayout: 'admin' },
     // Set layout for multiple routes
     '/dashboard/**': { appLayout: 'dashboard' },
+    // Disable layout for a route
+    '/landing': { appLayout: false },
   },
 })
 ```
 
+::tip
+This is useful when you want to manage layouts centrally in your configuration rather than in each page file, or when you need to apply layouts to routes that don't have corresponding page components (such as catchall pages which might match many paths).
+::
+
 :link-example{to="/docs/4.x/examples/features/layouts"}
 
 ## Overriding a Layout on a Per-page Basis

package/3.guide/1.concepts/5.modules.md

@@ -41,6 +41,19 @@ export default defineNuxtConfig({
 Nuxt modules are now build-time-only, and the `buildModules` property used in Nuxt 2 is deprecated in favor of `modules`.
 ::
 
+## Disabling Modules
+
+You can disable a module by setting its config key to `false` in your Nuxt config. This is particularly useful when you want to disable modules inherited from layers.
+
+```ts [nuxt.config.ts]
+export default defineNuxtConfig({
+  // Disable `@nuxt/image` module
+  image: false,
+})
+```
+
+:read-more{to="/docs/4.x/guide/going-further/layers#disabling-modules-from-layers"}
+
 ## Create a Nuxt Module
 
 Everyone has the opportunity to develop modules and we cannot wait to see what you will build.

package/3.guide/6.going-further/1.experimental-features.md

@@ -248,6 +248,21 @@ export default defineNuxtConfig({
 })
 ```
 
+Payload extraction also works for routes using ISR (Incremental Static Regeneration) or SWR (Stale-While-Revalidate) caching strategies. This allows CDNs to cache payload files alongside HTML, improving client-side navigation performance for cached routes.
+
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  experimental: {
+    payloadExtraction: true,
+  },
+  routeRules: {
+    // Payload files will be generated for these cached routes
+    '/products/**': { isr: 3600 },
+    '/blog/**': { swr: true },
+  },
+})
+```
+
 ## clientFallback
 
 Enables the experimental [`<NuxtClientFallback>`](/docs/4.x/api/components/nuxt-client-fallback) component for rendering content on the client if there's an error in SSR.

package/3.guide/6.going-further/7.layers.md

@@ -249,6 +249,32 @@ export default defineNuxtConfig({
 })
 ```
 
+## Disabling Modules from Layers
+
+When extending a layer, you might want to disable certain modules that it includes. You can do this by setting the module's config key to `false` in your Nuxt config.
+
+```ts [nuxt.config.ts]
+export default defineNuxtConfig({
+  extends: ['./base-layer'],
+  // Disable modules from the layer by setting their config key to false
+  image: false, // Disables @nuxt/image
+  pinia: false, // Disables @pinia/nuxt
+})
+```
+
+::note
+The config key is defined by each module. Common examples include `image` for `@nuxt/image`, `pinia` for `@pinia/nuxt`, and `content` for `@nuxt/content`. Check the module's documentation for its specific config key.
+::
+
+This is useful when:
+- A layer includes modules you don't need in your project
+- You want to use a different implementation than what the layer provides
+- You need to disable analytics or other modules in specific environments
+
+::tip
+You can also use this approach to disable modules in your own project - not just those from layers. Setting a module's config key to `false` will prevent its setup function from running while still generating types for the module.
+::
+
 ## Multi-Layer Support for Nuxt Modules
 
 You can use the [`getLayerDirectories`](/docs/4.x/api/kit/layers#getlayerdirectories) utility from Nuxt Kit to support custom multi-layer handling for your modules.

package/4.api/1.components/1.nuxt-client-fallback.md

@@ -54,6 +54,10 @@ This component is experimental and in order to use it you must enable the `exper
   - **type**: `boolean`
   - **default**: `false`
 
+::warning{icon="i-ph-warning-duotone"}
+The `placeholder` and `fallback` props render content as raw HTML. Do not pass untrusted user input to these props as it may lead to XSS vulnerabilities. Use the `#fallback` or `#placeholder` slots instead for dynamic content that needs proper escaping.
+::
+
 ```vue
 <template>
   <!-- render <span>Hello world</span> server-side if the default slot fails to render -->

package/4.api/1.components/8.nuxt-island.md

@@ -32,13 +32,20 @@ Server only components use `<NuxtIsland>` under the hood
   - **type**: `Record<string, any>`
 - `source`: Remote source to call the island to render.
   - **type**: `string`
-- **dangerouslyLoadClientComponents**: Required to load components from a remote source.
+- **dangerouslyLoadClientComponents**: Required to load client components from a remote source.
   - **type**: `boolean`
   - **default**: `false`
 
 ::note
 Remote islands need `experimental.componentIslands` to be `'local+remote'` in your `nuxt.config`.
-It is strongly discouraged to enable `dangerouslyLoadClientComponents` as you can't trust a remote server's javascript.
+::
+
+::warning{icon="i-ph-warning-duotone"}
+Using the `source` prop to render content from a remote server is inherently dangerous. When you specify a remote `source`, you are fully trusting that server to provide safe HTML content that will be rendered directly in your application.
+
+This is similar to using `v-html` with external content - the remote server can inject any HTML, including potentially malicious content. **Only use `source` with servers you fully trust and control.**
+
+The `dangerouslyLoadClientComponents` prop controls an additional layer of risk: whether to also download and execute client components from the remote source. Even with `dangerouslyLoadClientComponents` disabled (the default), you are still trusting the remote server's HTML output.
 ::
 
 ::note

package/4.api/3.utils/set-page-layout.md

@@ -19,6 +19,42 @@ export default defineNuxtRouteMiddleware((to) => {
 })
 ```
 
+## Passing Props to Layouts
+
+You can pass props to the layout by providing an object as the second argument:
+
+```ts [app/middleware/admin-layout.ts]
+export default defineNuxtRouteMiddleware((to) => {
+  setPageLayout('admin', {
+    sidebar: true,
+    title: 'Dashboard',
+  })
+})
+```
+
+The layout can then receive these props:
+
+```vue [app/layouts/admin.vue]
+<script setup lang="ts">
+const props = defineProps<{
+  sidebar?: boolean
+  title?: string
+}>()
+</script>
+
+<template>
+  <div>
+    <aside v-if="sidebar">
+      Sidebar
+    </aside>
+    <main>
+      <h1>{{ title }}</h1>
+      <slot />
+    </main>
+  </div>
+</template>
+```
+
 ::note
 If you choose to set the layout dynamically on the server side, you _must_ do so before the layout is rendered by Vue (that is, within a plugin or route middleware) to avoid a hydration mismatch.
 ::

package/4.api/5.kit/1.modules.md

@@ -103,6 +103,19 @@ export default defineNuxtConfig({
 })
 ```
 
+Users can also completely disable a module by setting the config key to `false`. This prevents the module's setup function from running while still generating types for module options.
+
+```ts
+export default defineNuxtConfig({
+  // Disable the module entirely
+  myModule: false,
+})
+```
+
+::tip
+This is particularly useful when you want to disable modules inherited from [Nuxt layers](/docs/4.x/guide/going-further/layers#disabling-modules-from-layers).
+::
+
 #### Defining Module Compatibility Requirements
 
 If you're developing a Nuxt module and using APIs that are only supported in specific Nuxt versions, it's highly recommended to include `compatibility.nuxt`.

package/4.api/5.kit/14.builder.md

@@ -207,7 +207,19 @@ See [Vite website](https://vite.dev/guide/api-plugin) for more information about
 
 ### Parameters
 
-**`pluginOrGetter`**: A Vite plugin instance or an array of Vite plugin instances. If a function is provided, it must return a Vite plugin instance or an array of Vite plugin instances.
+**`pluginOrGetter`**: A Vite plugin instance or an array of Vite plugin instances. If a function is provided, it must return a Vite plugin instance or an array of Vite plugin instances. The function can also be async or return a Promise, which is useful for lazy-loading plugins:
+
+```ts twoslash
+// @errors: 2307
+import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup () {
+    // Lazy load the plugin - only imported when the build actually runs
+    addVitePlugin(() => import('my-vite-plugin').then(r => r.default()))
+  },
+})
+```
 
 **`options`**: Options to pass to the callback function. This object can have the following properties:
 
@@ -266,7 +278,7 @@ See [webpack website](https://webpack.js.org/concepts/plugins/) for more informa
 
 ### Parameters
 
-**`pluginOrGetter`**: A webpack plugin instance or an array of webpack plugin instances. If a function is provided, it must return a webpack plugin instance or an array of webpack plugin instances.
+**`pluginOrGetter`**: A webpack plugin instance or an array of webpack plugin instances. If a function is provided, it must return a webpack plugin instance or an array of webpack plugin instances. The function can also be async or return a Promise, enabling lazy-loading of plugins.
 
 **`options`**: Options to pass to the callback function. This object can have the following properties:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nuxt/docs-nightly",
-  "version": "4.3.0-29481970.f136022c",
+  "version": "4.3.0-29483992.8d4f9ba5",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/nuxt/nuxt.git",