@nuxt/docs 3.19.3 → 3.20.1

package/1.getting-started/02.installation.md

@@ -28,10 +28,10 @@ Or follow the steps below to set up a new Nuxt project on your computer.
 ::note
   ::details
   :summary[Additional notes for an optimal setup:]
-  - **Node.js**: Make sure to use an even numbered version (18, 20, etc)
+  - **Node.js**: Make sure to use an even numbered version (20, 22, etc.)
   - **Nuxtr**: Install the community-developed [Nuxtr extension](https://marketplace.visualstudio.com/items?itemName=Nuxtr.nuxtr-vscode)
-  - **WSL**: If you are using Windows and experience slow HMR, you may want to try using [WSL (Windows Subsystem for Linux)](https://docs.microsoft.com/en-us/windows/wsl/install) which may solve some performance issues.
-  - **Windows slow DNS resolution** - instead of using `localhost:3000` for local dev server on Windows, use `127.0.0.1` for much faster loading experience on browsers.
+  - **WSL**: If you are using Windows and experience slow HMR, you may want to try using [WSL (Windows Subsystem for Linux)](https://learn.microsoft.com/en-us/windows/wsl/install) which may solve some performance issues.
+  - **Windows slow DNS resolution**: Instead of using `localhost:3000` for local dev server on Windows, use `127.0.0.1` for much faster loading experience on browsers.
   ::
 ::
 

package/1.getting-started/07.routing.md

@@ -90,6 +90,10 @@ Nuxt provides a customizable route middleware framework you can use throughout y
 Route middleware runs within the Vue part of your Nuxt app. Despite the similar name, they are completely different from server middleware, which are run in the Nitro server part of your app.
 ::
 
+::important
+Route middleware does **not** run for server routes (e.g. `/api/*`) or other server requests. To apply middleware to these requests, use [server middleware](/docs/3.x/guide/directory-structure/server#server-middleware) instead.
+::
+
 There are three kinds of route middleware:
 
 1. Anonymous (or inline) route middleware, which are defined directly in the pages where they are used.

package/1.getting-started/10.data-fetching.md

@@ -194,10 +194,10 @@ The `useAsyncData` composable is a great way to wrap and wait for multiple `$fet
 
 ```vue
 <script setup lang="ts">
-const { data: discounts, status } = await useAsyncData('cart-discount', async () => {
+const { data: discounts, status } = await useAsyncData('cart-discount', async (_nuxtApp, { signal }) => {
   const [coupons, offers] = await Promise.all([
-    $fetch('/cart/coupons'),
-    $fetch('/cart/offers'),
+    $fetch('/cart/coupons', { signal }),
+    $fetch('/cart/offers', { signal }),
   ])
 
   return { coupons, offers }
@@ -372,8 +372,8 @@ The following options **must be consistent** across all calls with the same key:
 
 ```ts
 // ❌ This will trigger a development warning
-const { data: users1 } = useAsyncData('users', () => $fetch('/api/users'), { deep: false })
-const { data: users2 } = useAsyncData('users', () => $fetch('/api/users'), { deep: true })
+const { data: users1 } = useAsyncData('users', (_nuxtApp, { signal }) => $fetch('/api/users', { signal }), { deep: false })
+const { data: users2 } = useAsyncData('users', (_nuxtApp, { signal }) => $fetch('/api/users', { signal }), { deep: true })
 ```
 
 The following options **can safely differ** without triggering warnings:
@@ -385,16 +385,16 @@ The following options **can safely differ** without triggering warnings:
 
 ```ts
 // ✅ This is allowed
-const { data: users1 } = useAsyncData('users', () => $fetch('/api/users'), { immediate: true })
-const { data: users2 } = useAsyncData('users', () => $fetch('/api/users'), { immediate: false })
+const { data: users1 } = useAsyncData('users', (_nuxtApp, { signal }) => $fetch('/api/users', { signal }), { immediate: true })
+const { data: users2 } = useAsyncData('users', (_nuxtApp, { signal }) => $fetch('/api/users', { signal }), { immediate: false })
 ```
 
 If you need independent instances, use different keys:
 
 ```ts
 // These are completely independent instances
-const { data: users1 } = useAsyncData('users-1', () => $fetch('/api/users'))
-const { data: users2 } = useAsyncData('users-2', () => $fetch('/api/users'))
+const { data: users1 } = useAsyncData('users-1', (_nuxtApp, { signal }) => $fetch('/api/users', { signal }))
+const { data: users2 } = useAsyncData('users-2', (_nuxtApp, { signal }) => $fetch('/api/users', { signal }))
 ```
 
 #### Reactive Keys
@@ -804,10 +804,10 @@ while (true) {
 When requests don't rely on each other, you can make them in parallel with `Promise.all()` to boost performance.
 
 ```ts
-const { data } = await useAsyncData(() => {
+const { data } = await useAsyncData((_nuxtApp, { signal }) => {
   return Promise.all([
-    $fetch('/api/comments/'),
-    $fetch('/api/author/12'),
+    $fetch('/api/comments/', { signal }),
+    $fetch('/api/author/12', { signal }),
   ])
 })
 

package/1.getting-started/14.layers.md

@@ -80,27 +80,46 @@ Nuxt uses [unjs/c12](https://c12.unjs.io) and [unjs/giget](https://giget.unjs.io
 
 ## Layer Priority
 
-When using multiple layers, it's important to understand how they override each other:
+When using multiple layers, it's important to understand the override order. Layers with **higher priority** override layers with lower priority when they define the same files or components.
 
-1. **Layers in `extends`** - earlier entries have higher priority (first overrides second)
-2. **Auto-scanned local layers** from `~~/layers` directory in alphabetical order (Z overrides A)  
-3. **Your project** has the highest priority in the stack - it will always override other layers
+The priority order from highest to lowest is:
+
+1. **Your project files** - always have the highest priority
+2. **Auto-scanned layers** from `~~/layers` directory - sorted alphabetically (Z has higher priority than A)
+3. **Layers in `extends`** config - first entry has higher priority than second
+
+### When to Use Each
+
+- **`extends`** - Use for external dependencies (npm packages, remote repositories) or layers outside your project directory
+- **`~~/layers` directory** - Use for local layers that are part of your project
+
+::tip
+If you need to control the order of auto-scanned layers, you can prefix them with numbers: `~/layers/1.z-layer`, `~/layers/2.a-layer`. This way `2.a-layer` will have higher priority than `1.z-layer`.
+::
+
+### Example
 
 ```ts [nuxt.config.ts]
 export default defineNuxtConfig({
   extends: [
-    // Highest priority (among extends)
+    // Local layer outside the project
     '../base',
-    // Medium priority
+    // NPM package
     '@my-themes/awesome',
-    // Lower priority
+    // Remote repository
     'github:my-themes/awesome#v1',
   ],
-  // Your project has the highest priority
 })
 ```
 
-This means if multiple layers define the same component, configuration, or file, the one with higher priority will be used.
+If you also have `~~/layers/custom`, the priority order is:
+- Your project files (highest)
+- `~~/layers/custom`
+- `../base`
+- `@my-themes/awesome`
+- `github:my-themes/awesome#v1` (lowest)
+
+This means your project files will override any layer, and `~~/layers/custom` will override anything in `extends`.
 
 ::read-more{to="/docs/guide/going-further/layers"}
 Read more about layers in the **Layer Author Guide**.

package/1.getting-started/18.upgrade.md

@@ -120,19 +120,23 @@ You can run all the codemods mentioned in this guide using the following `codemo
 ::code-group
 
 ```bash [npm]
-npx codemod@latest nuxt/4/migration-recipe
+# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+npx codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
 ```bash [yarn]
-yarn dlx codemod@latest nuxt/4/migration-recipe
+# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+yarn dlx codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
 ```bash [pnpm]
-pnpm dlx codemod@latest nuxt/4/migration-recipe
+# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+pnpm dlx codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
 ```bash [bun]
-bun x codemod@latest nuxt/4/migration-recipe
+# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+bun x codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
 ::

package/2.guide/1.directory-structure/1.node_modules.md

@@ -5,7 +5,7 @@ head.title: "node_modules/"
 navigation.icon: i-vscode-icons-folder-type-node
 ---
 
-The package manager ([`npm`](https://docs.npmjs.com/cli/commands/npm) or [`yarn`](https://yarnpkg.com) or [`pnpm`](https://pnpm.io/cli/install) or [`bun`](https://bun.sh/package-manager)) creates this directory to store the dependencies of your project.
+The package manager ([`npm`](https://docs.npmjs.com/cli/commands/npm/) or [`yarn`](https://yarnpkg.com) or [`pnpm`](https://pnpm.io/cli/install) or [`bun`](https://bun.com/package-manager)) creates this directory to store the dependencies of your project.
 
 ::important
 This directory should be added to your [`.gitignore`](/docs/3.x/guide/directory-structure/gitignore) file to avoid pushing the dependencies to your repository.

package/2.guide/1.directory-structure/3.tsconfig.md

@@ -22,3 +22,26 @@ As you need to, you can customize the contents of this file. However, it is reco
 ::note
 If you need to customize your `paths`, this will override the auto-generated path aliases. Instead, we recommend that you add any path aliases you need to the [`alias`](/docs/3.x/api/nuxt-config#alias) property within your `nuxt.config`, where they will get picked up and added to the auto-generated `tsconfig`.
 ::
+
+## Extending TypeScript Configuration
+
+You can customize the TypeScript configuration of your Nuxt project for each context (`app` and `server`) in the `nuxt.config.ts` file.
+<!-- @case-police-ignore tsConfig -->
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  typescript: {
+    // customize tsconfig.app.json
+    tsConfig: {
+      // ...
+    },
+  },
+  nitro: {
+    typescript: {
+      // customize tsconfig.server.json
+      tsConfig: {
+        // ...
+      },
+    },
+  },
+})
+```

package/2.guide/2.concepts/7.esm.md

@@ -50,6 +50,10 @@ When adding modules to your package, things were a little different. A sample li
 
 So in Nuxt 2, the bundler (webpack) would pull in the CJS file ('main') for the server build and use the ESM file ('module') for the client build.
 
+::note
+The `module` field is a convention used by bundlers like webpack and Rollup, but is not recognized by Node.js itself. Node.js only uses the [`exports`](https://nodejs.org/api/packages.html#exports) and [`main`](https://nodejs.org/api/packages.html#main) fields for module resolution.
+::
+
 However, in recent Node.js LTS releases, it is now possible to [use native ESM module](https://nodejs.org/api/esm.html) within Node.js. That means that Node.js itself can process JavaScript using ESM syntax, although it doesn't do it by default. The two most common ways to enable ESM syntax are:
 
 - set `"type": "module"` within your `package.json` and keep using `.js` extension
@@ -59,7 +63,7 @@ This is what we do for Nuxt Nitro; we output a `.output/server/index.mjs` file.
 
 ### What Are Valid Imports in a Node.js Context?
 
-When you `import` a module rather than `require` it, Node.js resolves it differently. For example, when you import `sample-library`, Node.js will look not for the `main` but for the `exports` or `module` entry in that library's `package.json`.
+When you `import` a module rather than `require` it, Node.js resolves it differently. For example, when you import `sample-library`, Node.js will look for the `exports` entry in that library's `package.json`, or fall back to the `main` entry if `exports` is not defined.
 
 This is also true of dynamic imports, like `const b = await import('sample-library')`.
 

package/2.guide/2.concepts/9.code-style.md

@@ -8,7 +8,7 @@ description: "Nuxt supports ESLint out of the box"
 The recommended approach for Nuxt is to enable ESLint support using the [`@nuxt/eslint`](https://eslint.nuxt.com/packages/module) module, that will setup project-aware ESLint configuration for you.
 
 :::callout{icon="i-lucide-lightbulb"}
-The module is designed for the [new ESLint flat config format](https://eslint.org/docs/latest/use/configure/configuration-files-new) with is the [default format since ESLint v9](https://eslint.org/blog/2024/04/eslint-v9.0.0-released/). If you are using the legacy `.eslintrc` config, you will need to [configure manually with `@nuxt/eslint-config`](https://eslint.nuxt.com/packages/config#legacy-config-format). We highly recommend you to migrate over the flat config to be future-proof.
+The module is designed for the [new ESLint flat config format](https://eslint.org/docs/latest/use/configure/configuration-files-new) which is the [default format since ESLint v9](https://eslint.org/blog/2024/04/eslint-v9.0.0-released/). If you are using the legacy `.eslintrc` config, you will need to [configure manually with `@nuxt/eslint-config`](https://eslint.nuxt.com/packages/config#legacy-config-format). We highly recommend you to migrate over the flat config to be future-proof.
 :::
 
 ## Quick Setup

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

@@ -71,6 +71,44 @@ export default defineNuxtConfig({
 })
 ```
 
+## extractAsyncDataHandlers
+
+Extracts handler functions from `useAsyncData` and `useLazyAsyncData` calls into separate chunks for improved code splitting and caching efficiency.
+
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  experimental: {
+    extractAsyncDataHandlers: true,
+  },
+})
+```
+
+This feature transforms inline handler functions into dynamically imported chunks:
+
+```vue
+<!-- Before -->
+<script setup>
+const { data } = await useAsyncData('user', async () => {
+  return await $fetch('/api/user')
+})
+</script>
+```
+
+```vue
+<!-- After transformation -->
+<script setup>
+const { data } = await useAsyncData('user', () =>
+  import('/generated-chunk.js').then(r => r.default()),
+)
+</script>
+```
+
+The benefit of this transformation is that we can split out data fetching logic &mdash; while still allowing the code to be loaded if required.
+
+::important
+This feature is only recommended for **static builds** with payload extraction, and where data does not need to be re-fetched at runtime.
+::
+
 ## emitRouteChunkError
 
 Emits `app:chunkError` hook when there is an error loading vite/webpack chunks. Default behavior is to perform a reload of the new route on navigation to a new route when a chunk fails to load.
@@ -359,12 +397,12 @@ should do this automatically for you.)
 // This would be unsafe in a dynamic page (e.g. `[slug].vue`) because the route slug makes a difference
 // to the data fetched, but Nuxt can't know that because it's not reflected in the key.
 const route = useRoute()
-const { data } = await useAsyncData(async () => {
-  return await $fetch(`/api/my-page/${route.params.slug}`)
+const { data } = await useAsyncData(async (_nuxtApp, { signal }) => {
+  return await $fetch(`/api/my-page/${route.params.slug}`, { signal })
 })
 // Instead, you should use a key that uniquely identifies the data fetched.
-const { data } = await useAsyncData(route.params.slug, async () => {
-  return await $fetch(`/api/my-page/${route.params.slug}`)
+const { data } = await useAsyncData(route.params.slug, async (_nuxtApp, { signal }) => {
+  return await $fetch(`/api/my-page/${route.params.slug}`, { signal })
 })
 ```
 
@@ -721,3 +759,53 @@ export default defineNuxtConfig({
   },
 })
 ```
+
+## typescriptPlugin
+
+Enable enhanced TypeScript developer experience with the `@dxup/nuxt` module.
+
+This experimental plugin provides improved TypeScript integration and development tooling for better DX when working with TypeScript in Nuxt applications.
+
+This flag is disabled by default, but you can enable this feature:
+
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  experimental: {
+    typescriptPlugin: true,
+  },
+})
+```
+
+::important
+To use this feature, you need to:
+- Have `typescript` installed as a dependency
+- Configure VS Code to use your workspace TypeScript version (see [VS Code documentation](https://code.visualstudio.com/docs/typescript/typescript-compiling#_using-the-workspace-version-of-typescript))
+::
+
+::read-more{icon="i-simple-icons-github" to="https://github.com/KazariEX/dxup" target="_blank"}
+Learn more about **@dxup/nuxt**.
+::
+
+## viteEnvironmentApi
+
+Enable Vite 6's new [Environment API](https://vite.dev/guide/api-environment) for improved build configuration and plugin architecture.
+
+When you set `future.compatibilityVersion` to `5`, this feature is enabled by default. You can also enable it explicitly for testing:
+
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  experimental: {
+    viteEnvironmentApi: true,
+  },
+})
+```
+
+The Vite Environment API provides better consistency between development and production builds, more granular control over environment-specific configuration, and improved performance.
+
+::important
+Enabling this feature changes how Vite plugins are registered and configured. See the [Vite Environment API migration guide](/docs/4.x/getting-started/upgrade#migration-to-vite-environment-api) for details on updating your plugins.
+::
+
+::read-more{to="https://vite.dev/guide/api-environment" target="_blank"}
+Learn more about Vite's Environment API.
+::

package/2.guide/3.going-further/3.modules.md

@@ -501,35 +501,51 @@ export default defineNuxtModule({
 
 #### Using Other Modules in Your Module
 
-If your module depends on other modules, you can add them by using Nuxt Kit's `installModule` utility. For example, if you wanted to use Nuxt Tailwind in your module, you could add it as below:
+If your module depends on other modules, you can specify them using the `moduleDependencies` option. This provides a more robust way to handle module dependencies with version constraints and configuration merging:
 
 ```ts
-import { createResolver, defineNuxtModule, installModule } from '@nuxt/kit'
-
-export default defineNuxtModule<ModuleOptions>({
-  async setup (options, nuxt) {
-    const resolver = createResolver(import.meta.url)
+import { createResolver, defineNuxtModule } from '@nuxt/kit'
 
-    // We can inject our CSS file which includes Tailwind's directives
-    nuxt.options.css.push(resolver.resolve('./runtime/assets/styles.css'))
+const resolver = createResolver(import.meta.url)
 
-    await installModule('@nuxtjs/tailwindcss', {
-      // module configuration
-      exposeConfig: true,
-      config: {
-        darkMode: 'class',
-        content: {
-          files: [
-            resolver.resolve('./runtime/components/**/*.{vue,mjs,ts}'),
-            resolver.resolve('./runtime/*.{mjs,js,ts}'),
-          ],
+export default defineNuxtModule<ModuleOptions>({
+  meta: {
+    name: 'my-module',
+  },
+  moduleDependencies: {
+    '@nuxtjs/tailwindcss': {
+      // You can specify a version constraint for the module
+      version: '>=6',
+      // Any configuration that should override `nuxt.options`
+      overrides: {
+        exposeConfig: true,
+      },
+      // Any configuration that should be set. It will override module defaults but
+      // will not override any configuration set in `nuxt.options`
+      defaults: {
+        config: {
+          darkMode: 'class',
+          content: {
+            files: [
+              resolver.resolve('./runtime/components/**/*.{vue,mjs,ts}'),
+              resolver.resolve('./runtime/*.{mjs,js,ts}'),
+            ],
+          },
         },
       },
-    })
+    },
+  },
+  setup (options, nuxt) {
+    // We can inject our CSS file which includes Tailwind's directives
+    nuxt.options.css.push(resolver.resolve('./runtime/assets/styles.css'))
   },
 })
 ```
 
+::callout{type="info"}
+The `moduleDependencies` option replaces the deprecated `installModule` function and ensures proper setup order and configuration merging.
+::
+
 #### Using Hooks
 
 [Lifecycle hooks](/docs/3.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.
@@ -758,7 +774,7 @@ An example of such a workflow is available on [the module starter](https://githu
 
 Having a playground Nuxt application to test your module when developing it is really useful. [The module starter integrates one for that purpose](#how-to-develop).
 
-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"`.
+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"`.
 
 After that, you should be able to reference `my-module` like in any regular project.
 

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

@@ -68,29 +68,46 @@ Additionally, certain other files in the layer directory will be auto-scanned an
 
 ## Layer Priority
 
-When extending from multiple layers, it's important to understand the priority order:
+When extending from multiple layers, it's important to understand the override order. Layers with **higher priority** override layers with lower priority when they define the same files or components.
 
-1. **Layers in `extends`** - earlier entries have higher priority (first overrides second)
-2. **Auto-scanned local layers** from `~~/layers` directory in alphabetical order (Z overrides A)
-3. **Your project** has the highest priority in the stack - it will always override other layers
+The priority order from highest to lowest is:
 
-For example:
+1. **Your project files** - always have the highest priority
+2. **Auto-scanned layers** from `~~/layers` directory - sorted alphabetically (Z has higher priority than A)
+3. **Layers in `extends`** config - first entry has higher priority than second
+
+### When to Use Each
+
+- **`extends`** - Use for external dependencies (npm packages, remote repositories) or layers outside your project directory
+- **`~~/layers` directory** - Use for local layers that are part of your project
+
+::tip
+If you need to control the order of auto-scanned layers, you can prefix them with numbers: `~/layers/1.z-layer`, `~/layers/2.a-layer`. This way `2.a-layer` will have higher priority than `1.z-layer`.
+::
+
+### Example
 
 ```ts [nuxt.config.ts]
 export default defineNuxtConfig({
   extends: [
-    // Highest priority (among extends)
-    './layers/base',
-    // Medium priority
-    './layers/theme',
-    // Lower priority
-    './layers/custom',
+    // Local layer outside the project
+    '../base',
+    // NPM package
+    '@my-themes/awesome',
+    // Remote repository
+    'github:my-themes/awesome#v1',
   ],
-  // Your project has the highest priority
 })
 ```
 
-If you also have auto-scanned layers like `~~/layers/a` and `~~/layers/z`, the complete override order would be: `base` > `theme` > `custom` > `z` > `a` > your project.
+If you also have `~~/layers/custom`, the priority order is:
+- Your project files (highest)
+- `~~/layers/custom`
+- `../base`
+- `@my-themes/awesome`
+- `github:my-themes/awesome#v1` (lowest)
+
+This means your project files will override any layer, and `~~/layers/custom` will override anything in `extends`.
 
 ## Starter Template
 
@@ -234,22 +251,30 @@ export default defineNuxtConfig({
 
 ## Multi-Layer Support for Nuxt Modules
 
-You can use the internal array `nuxt.options._layers` to support custom multi-layer handling for your modules.
+You can use the [`getLayerDirectories`](/docs/api/kit/layers#getlayerdirectories) utility from Nuxt Kit to support custom multi-layer handling for your modules.
 
 ```ts [modules/my-module.ts]
+import { defineNuxtModule, getLayerDirectories } from 'nuxt/kit'
+
 export default defineNuxtModule({
   setup (_options, nuxt) {
-    for (const layer of nuxt.options._layers) {
-      // You can check for a custom directory existence to extend for each layer
-      console.log('Custom extension for', layer.cwd, layer.config)
+    const layerDirs = getLayerDirectories()
+
+    for (const [index, layer] of layerDirs.entries()) {
+      console.log(`Layer ${index}:`)
+      console.log(`  Root: ${layer.root}`)
+      console.log(`  App: ${layer.app}`)
+      console.log(`  Server: ${layer.server}`)
+      console.log(`  Pages: ${layer.appPages}`)
+      // ... other directories
     }
   },
 })
 ```
 
 **Notes:**
-- Earlier items in the `_layers` array have higher priority and override later ones
-- The user's project is the first item in the `_layers` array
+- Earlier items in the array have higher priority and override later ones
+- The user's project is the first item in the array
 
 ## Going Deeper
 

package/2.guide/4.recipes/2.vite-plugin.md

@@ -63,3 +63,44 @@ import config from '~/data/hello.yaml'
 ```
 
 ::
+
+## Using Vite Plugins in Nuxt Modules
+
+If you're developing a Nuxt module and need to add Vite plugins, you should use the [`addVitePlugin`](/docs/3.x/api/kit/builder#addviteplugin) utility:
+
+```ts [modules/my-module.ts]
+import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'
+import yaml from '@rollup/plugin-yaml'
+
+export default defineNuxtModule({
+  setup () {
+    addVitePlugin(yaml())
+  },
+})
+```
+
+For environment-specific plugins in Nuxt 5+, use the `applyToEnvironment()` method:
+
+```ts [modules/my-module.ts]
+import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup () {
+    addVitePlugin(() => ({
+      name: 'my-client-plugin',
+      applyToEnvironment (environment) {
+        return environment.name === 'client'
+      },
+      // Plugin configuration
+    }))
+  },
+})
+```
+
+::important
+If you're writing code that needs to access resolved Vite configuration, you should use the `config` and `configResolved` hooks _within_ your Vite plugin, rather than using Nuxt's `vite:extend`, `vite:extendConfig` and `vite:configResolved`.
+::
+
+::read-more{to="/docs/3.x/api/kit/builder#addviteplugin"}
+Read more about `addVitePlugin` in the Nuxt Kit documentation.
+::

package/3.api/1.components/13.nuxt-time.md

@@ -104,13 +104,17 @@ Enables relative time formatting using the Intl.RelativeTimeFormat API:
 
 When `relative` is set to `true`, the component also accepts properties from [Intl.RelativeTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat/RelativeTimeFormat):
 
+::warning
+Due to `style` being a reserved prop, `relativeStyle` prop is used instead.
+::
+
 ```vue
 <template>
   <NuxtTime
     :datetime="Date.now() - 3 * 24 * 60 * 60 * 1000"
     relative
     numeric="auto"
-    style="long"
+    relative-style="long"
   />
 </template>
 ```