@nuxt/docs 3.17.6 → 3.18.0

package/1.getting-started/01.introduction.md

@@ -24,7 +24,7 @@ Nuxt uses conventions and an opinionated directory structure to automate repetit
 - **Server-side rendering out of the box:** Nuxt comes with built-in SSR capabilities, so you don't have to set up a separate server yourself.
 - **Auto-imports:** write Vue composables and components in their respective directories and use them without having to import them with the benefits of tree-shaking and optimized JS bundles.
 - **Data-fetching utilities:** Nuxt provides composables to handle SSR-compatible data fetching as well as different strategies.
-- **Zero-config TypeScript support:** write type-safe code without having to learn TypeScript with our auto-generated types and `tsconfig.json`
+- **Zero-config TypeScript support:** write type-safe code without having to learn TypeScript with our auto-generated types and `tsconfig.json`.
 - **Configured build tools:** we use [Vite](https://vite.dev) by default to support hot module replacement (HMR) in development and bundling your code for production with best-practices baked-in.
 
 Nuxt takes care of these and provides both frontend and backend functionality so you can focus on what matters: **creating your web application**.
@@ -64,7 +64,7 @@ A Nuxt application can be deployed on a Node or Deno server, pre-rendered to be
 
 ### Modular
 
-A module system allows to extend Nuxt with custom features and integrations with third-party services.
+A module system allows you to extend Nuxt with custom features and integrations with third-party services.
 
 :read-more{title="Nuxt Modules Concept" to="/docs/guide/concepts/modules"}
 

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

@@ -9,8 +9,8 @@ navigation.icon: i-lucide-play
 If you just want to play around with Nuxt in your browser without setting up a project, you can use one of our online sandboxes:
 
 ::card-group
-  :card{title="Open on StackBlitz" icon="i-simple-icons-stackblitz" to="https://nuxt.new/s/v3" target="_blank"}
-  :card{title="Open on CodeSandbox" icon="i-simple-icons-codesandbox" to="https://nuxt.new/c/v3" target="_blank"}
+  :card{title="Open on StackBlitz" icon="i-simple-icons-stackblitz" to="https://nuxt.new/s/v4" target="_blank"}
+  :card{title="Open on CodeSandbox" icon="i-simple-icons-codesandbox" to="https://nuxt.new/c/v4" target="_blank"}
 ::
 
 Or follow the steps below to set up a new Nuxt project on your computer.
@@ -39,23 +39,23 @@ Open a terminal (if you're using [Visual Studio Code](https://code.visualstudio.
 ::code-group{sync="pm"}
 
 ```bash [npm]
-npm create nuxt <project-name>
+npm create nuxt@latest <project-name> -- -t v3
 ```
 
 ```bash [yarn]
-yarn create nuxt <project-name>
+yarn create nuxt@latest <project-name> -t v3
 ```
 
 ```bash [pnpm]
-pnpm create nuxt <project-name>
+pnpm create nuxt@latest <project-name> -t v3
 ```
 
 ```bash [bun]
-bun create nuxt <project-name>
+bun create nuxt@latest <project-name> -t v3
 ```
 
 ```bash [deno]
-deno -A npm:create-nuxt@latest <project-name>
+deno -A npm:create-nuxt@latest <project-name> -t v3
 ```
 
 ::

package/1.getting-started/03.configuration.md

@@ -100,7 +100,7 @@ const runtimeConfig = useRuntimeConfig()
 
 ## App Configuration
 
-The `app.config.ts` file, located in the source directory (by default the root of the project), is used to expose public variables that can be determined at build time. Contrary to the `runtimeConfig` option, these can not be overridden using environment variables.
+The `app.config.ts` file, located in the source directory (by default the root of the project), is used to expose public variables that can be determined at build time. Contrary to the `runtimeConfig` option, these cannot be overridden using environment variables.
 
 A minimal configuration file exports the `defineAppConfig` function containing an object with your configuration. The `defineAppConfig` helper is globally available without import.
 

package/1.getting-started/04.views.md

@@ -88,7 +88,7 @@ To use pages, create `pages/index.vue` file and add `<NuxtPage />` component to
 
 ![Layouts are wrapper around pages](/assets/docs/getting-started/views/layouts.svg)
 
-Layouts are wrappers around pages that contain a common User Interface for several pages, such as a header and footer display. Layouts are Vue files using `<slot />` components to display the **page** content. The `layouts/default.vue` file will be used by default. Custom layouts can be set as part of your page metadata.
+Layouts are wrappers around pages that contain a common User Interface for several pages, such as header and footer displays. Layouts are Vue files using `<slot />` components to display the **page** content. The `layouts/default.vue` file will be used by default. Custom layouts can be set as part of your page metadata.
 
 ::note
 If you only have a single layout in your application, we recommend using [`app.vue`](/docs/guide/directory-structure/app) with [`<NuxtPage />`](/docs/api/components/nuxt-page) instead.

package/1.getting-started/06.styling.md

@@ -51,7 +51,7 @@ The stylesheets will be inlined in the HTML rendered by Nuxt, injected globally
 
 ### Working With Fonts
 
-Place your local fonts files in your `~/public/` directory, for example in `~/public/fonts`. You can then reference them in your stylesheets using `url()`.
+Place your local fonts files in your `public/` directory, for example in `public/fonts`. You can then reference them in your stylesheets using `url()`.
 
 ```css [assets/css/main.css]
 @font-face {
@@ -119,7 +119,7 @@ export default defineNuxtConfig({
 
 ## External Stylesheets
 
-You can include external stylesheets in your application by adding a link element in the head section of your nuxt.config file. You can achieve this result using different methods. Note that local stylesheets can also be included like this.
+You can include external stylesheets in your application by adding a link element in the head section of your nuxt.config file. You can achieve this result using different methods. Note that local stylesheets can also be included this way.
 
 You can manipulate the head with the [`app.head`](/docs/api/nuxt-config#head) property of your Nuxt configuration:
 
@@ -407,7 +407,7 @@ You can use [CSS Modules](https://github.com/css-modules/css-modules) with the m
 
 ### Preprocessors Support
 
-SFC style blocks support preprocessors syntax. Vite come with built-in support for .scss, .sass, .less, .styl and .stylus files without configuration. You just need to install them first, and they will be available directly in SFC with the lang attribute.
+SFC style blocks support preprocessor syntax. Vite comes with built-in support for .scss, .sass, .less, .styl and .stylus files without configuration. You just need to install them first, and they will be available directly in SFC with the lang attribute.
 
 ::code-group
 

package/1.getting-started/08.seo-meta.md

@@ -12,7 +12,7 @@ and numerous configuration options to manage your app's head and SEO meta tags.
 Providing an [`app.head`](/docs/api/nuxt-config#head) property in your [`nuxt.config.ts`](/docs/guide/directory-structure/nuxt-config) allows you to statically customize the head for your entire app.
 
 ::important
-This method does not allow you to provide reactive data. We recommend to use `useHead()` in `app.vue`.
+This method does not allow you to provide reactive data. We recommend using `useHead()` in `app.vue`.
 ::
 
 It's good practice to set tags here that won't change such as your site title default, language and favicon.
@@ -75,7 +75,7 @@ useHead({
 </script>
 ```
 
-We recommend to take a look at the [`useHead`](/docs/api/composables/use-head) and [`useHeadSafe`](/docs/api/composables/use-head-safe) composables.
+We recommend taking a look at the [`useHead`](/docs/api/composables/use-head) and [`useHeadSafe`](/docs/api/composables/use-head-safe) composables.
 
 ## `useSeoMeta`
 

package/1.getting-started/09.transitions.md

@@ -16,7 +16,7 @@ You can enable page transitions to apply an automatic transition for all your [p
 export default defineNuxtConfig({
   app: {
     pageTransition: { name: 'page', mode: 'out-in' }
-  },
+  }
 })
 ```
 
@@ -121,7 +121,7 @@ You can enable layout transitions to apply an automatic transition for all your
 export default defineNuxtConfig({
   app: {
     layoutTransition: { name: 'layout', mode: 'out-in' }
-  },
+  }
 })
 ```
 
@@ -470,4 +470,4 @@ export default defineNuxtRouteMiddleware(to => {
 
 ### Known Issues
 
-- If you perform data fetching within your page setup functions, that you may wish to reconsider using this feature for the moment. (By design, View Transitions completely freeze DOM updates whilst they are taking place.) We're looking at restrict the View Transition to the final moments before `<Suspense>` resolves, but in the interim you may want to consider carefully whether to adopt this feature if this describes you.
+- If you perform data fetching within your page setup functions, you may wish to reconsider using this feature for the moment. (By design, View Transitions completely freeze DOM updates whilst they are taking place.) We're looking at restricting the View Transition to the final moments before `<Suspense>` resolves, but in the interim you may want to consider carefully whether to adopt this feature if this describes you.

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

@@ -9,7 +9,7 @@ Nuxt comes with two composables and a built-in library to perform data-fetching
 In a nutshell:
 
 - [`$fetch`](/docs/api/utils/dollarfetch) is the simplest way to make a network request.
-- [`useFetch`](/docs/api/composables/use-fetch) is wrapper around `$fetch` that fetches data only once in [universal rendering](/docs/guide/concepts/rendering#universal-rendering).
+- [`useFetch`](/docs/api/composables/use-fetch) is a wrapper around `$fetch` that fetches data only once in [universal rendering](/docs/guide/concepts/rendering#universal-rendering).
 - [`useAsyncData`](/docs/api/composables/use-async-data) is similar to `useFetch` but offers more fine-grained control.
 
 Both `useFetch` and `useAsyncData` share a common set of options and patterns that we will detail in the last sections.
@@ -81,7 +81,7 @@ async function addTodo() {
 
 ::warning
 Beware that using only `$fetch` will not provide [network calls de-duplication and navigation prevention](#the-need-for-usefetch-and-useasyncdata). :br
-It is recommended to use `$fetch` for client-side interactions (event based) or combined with [`useAsyncData`](#useasyncdata) when fetching the initial component data.
+It is recommended to use `$fetch` for client-side interactions (event-based) or combined with [`useAsyncData`](#useasyncdata) when fetching the initial component data.
 ::
 
 ::read-more{to="/docs/api/utils/dollarfetch"}
@@ -483,7 +483,7 @@ If you need to change the URL based on a reactive value, you may want to use a [
 
 #### Computed URL
 
-Sometimes you may need to compute an URL from reactive values, and refresh the data each time these change. Instead of juggling your way around, you can attach each param as a reactive value. Nuxt will automatically use the reactive value and re-fetch each time it changes.
+Sometimes you may need to compute a URL from reactive values, and refresh the data each time these change. Instead of juggling your way around, you can attach each param as a reactive value. Nuxt will automatically use the reactive value and re-fetch each time it changes.
 
 ```vue
 <script setup lang="ts">

package/1.getting-started/12.error-handling.md

@@ -109,7 +109,7 @@ const handleError = () => clearError({ redirect: '/' })
 Read more about `error.vue` and its uses.
 ::
 
-For custom errors we highly recommend to use `onErrorCaptured` composable that can be called in a page/component setup function or `vue:error` runtime nuxt hook that can be configured in a nuxt plugin.
+For custom errors we highly recommend using `onErrorCaptured` composable that can be called in a page/component setup function or `vue:error` runtime nuxt hook that can be configured in a nuxt plugin.
 
 ```ts twoslash [plugins/error-handler.ts]
 export default defineNuxtPlugin(nuxtApp => {

package/1.getting-started/15.prerendering.md

@@ -99,7 +99,7 @@ export default defineNuxtConfig({
 });
 ```
 
-::read-more{to="https://nitro.build/config/#routerules"}
+::read-more{to="https://nitro.build/config#routerules"}
 Read more about Nitro's `routeRules` configuration.
 ::
 
@@ -177,7 +177,7 @@ export default defineNuxtConfig({
 
 ### `prerender:generate` Nitro hook
 
-This is called for each route during prerendering. You can use this for fine grained handling of each route that gets prerendered.
+This is called for each route during prerendering. You can use this for fine-grained handling of each route that gets prerendered.
 
 ```ts [nuxt.config.ts]
 export default defineNuxtConfig({

package/1.getting-started/16.deployment.md

@@ -62,7 +62,7 @@ By default, the workload gets distributed to the workers with the round robin st
 
 ### Learn More
 
-:read-more{to="https://nitro.build/deploy/node" title="the Nitro documentation for node-server preset"}
+:read-more{to="https://nitro.build/deploy/runtimes/node" title="the Nitro documentation for node-server preset"}
 
 :video-accordion{title="Watch Daniel Roe's short video on the topic" videoId="0x1H6K5yOfs"}
 

package/1.getting-started/17.testing.md

@@ -63,7 +63,7 @@ We currently ship an environment for unit testing code that needs a [Nuxt](https
 
 ::tip
 When importing `@nuxt/test-utils` in your vitest config, It is necessary to have `"type": "module"` specified in your `package.json` or rename your vitest config file appropriately.
-> ie. `vitest.config.m{ts,js}`.
+> i.e., `vitest.config.m{ts,js}`.
 ::
 
 ::tip
@@ -444,7 +444,7 @@ If you prefer to use `@vue/test-utils` on its own for unit testing in Nuxt, and
 
 2. Create a `vitest.config.ts` with the following content:
 
-   ```ts twoslash
+   ```ts
    import { defineConfig } from 'vitest/config'
    import vue from '@vitejs/plugin-vue'
 

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

@@ -179,6 +179,7 @@ layers/
 modules/
 node_modules/
 public/
+shared/
 server/
   api/
   middleware/
@@ -299,6 +300,64 @@ export default defineNuxtConfig({
 })
 ```
 
+### Corrected Module Loading Order in Layers
+
+🚦 **Impact Level**: Minimal
+
+#### What Changed
+
+The order in which modules are loaded when using [Nuxt layers](/docs/guide/going-further/layers) has been corrected. Previously, modules from the project root were loaded before modules from extended layers, which was the reverse of the expected behavior.
+
+Now modules are loaded in the correct order:
+
+1. **Layer modules first** (in extend order - deeper layers first)
+2. **Project modules last** (highest priority)
+
+This affects both:
+* Modules defined in the `modules` array in `nuxt.config.ts`
+* Auto-discovered modules from the `modules/` directory
+
+#### Reasons for Change
+
+This change ensures that:
+* Extended layers have lower priority than the consuming project
+* Module execution order matches the intuitive layer inheritance pattern
+* Module configuration and hooks work as expected in multi-layer setups
+
+#### Migration Steps
+
+**Most projects will not need changes**, as this corrects the loading order to match expected behavior.
+
+However, if your project was relying on the previous incorrect order, you may need to:
+
+1. **Review module dependencies**: Check if any modules depend on specific loading order
+2. **Adjust module configuration**: If modules were configured to work around the incorrect order
+3. **Test thoroughly**: Ensure all functionality works as expected with the corrected order
+
+Example of the new correct order:
+```ts
+// Layer: my-layer/nuxt.config.ts
+export default defineNuxtConfig({
+  modules: ['layer-module-1', 'layer-module-2']
+})
+
+// Project: nuxt.config.ts
+export default defineNuxtConfig({
+  extends: ['./my-layer'],
+  modules: ['project-module-1', 'project-module-2']
+})
+
+// Loading order (corrected):
+// 1. layer-module-1
+// 2. layer-module-2  
+// 3. project-module-1 (can override layer modules)
+// 4. project-module-2 (can override layer modules)
+```
+
+If you encounter issues with module order dependencies due to needing to register a hook, consider using the [`modules:done` hook](/docs/guide/going-further/modules#custom-hooks) for modules that need to call a hook. This is run after all other modules have been loaded, which means it is safe to use.
+
+👉 See [PR #31507](https://github.com/nuxt/nuxt/pull/31507) and [issue #25719](https://github.com/nuxt/nuxt/issues/25719) for more details.
+
 ### Deduplication of Route Metadata
 
 🚦 **Impact Level**: Minimal
@@ -407,7 +466,7 @@ export default defineNuxtPlugin({
 })
 ```
 
-While not required it's recommend to update any imports from `@unhead/vue` to `#imports` or `nuxt/app`.
+While not required it's recommended to update any imports from `@unhead/vue` to `#imports` or `nuxt/app`.
 
 ```diff
 -import { useHead } from '@unhead/vue'
@@ -777,7 +836,7 @@ This change should generally improve the expected behavior, but if you were expe
     query: { id },
     immediate: false
   )
-+ watch(id, execute, { once: true })
++ watch(id, () => execute(), { once: true })
 ```
 
 To opt out of this behavior:
@@ -973,6 +1032,129 @@ const importName = genSafeVariableName
 You can automate this step by running `npx codemod@latest nuxt/4/template-compilation-changes`
 ::
 
+### Default TypeScript Configuration Changes
+
+🚦 **Impact Level**: Minimal
+
+#### What Changed
+
+`compilerOptions.noUncheckedIndexedAccess` is now `true` instead of `false`.
+
+#### Reasons for Change
+
+This change is a follow up to a prior [3.12 config update](https://github.com/nuxt/nuxt/pull/27485) where we improved our defaults, mostly adhering to [TotalTypeScript's recommendations](https://www.totaltypescript.com/tsconfig-cheat-sheet).
+
+#### Migration Steps
+
+There are two approaches:
+
+1. Run a typecheck on your app and fix any new errors (recommended).
+
+2. Override the new default in your `nuxt.config.ts`:
+
+   <!-- @case-police-ignore tsConfig -->
+
+   ```ts
+   export default defineNuxtConfig({
+     typescript: {
+       tsConfig: {
+         compilerOptions: {
+           noUncheckedIndexedAccess: false
+         }
+       }
+     }
+   })
+   ```
+
+### TypeScript Configuration Splitting
+
+🚦 **Impact Level**: Minimal
+
+#### What Changed
+
+Nuxt now generates separate TypeScript configurations for different contexts to provide better type-checking experiences:
+
+1. **New TypeScript configuration files**: Nuxt now generates additional TypeScript configurations:
+   * `.nuxt/tsconfig.app.json` - For your app code (Vue components, composables, etc.)
+   * `.nuxt/tsconfig.server.json` - For your server-side code (Nitro/server directory)  
+   * `.nuxt/tsconfig.node.json` - For your build-time code (modules, `nuxt.config.ts`, etc.)
+   * `.nuxt/tsconfig.shared.json` - For code shared between app and server contexts (like types and non-environment specific utilities)
+   * `.nuxt/tsconfig.json` - Legacy configuration for backward compatibility
+
+2. **Backward compatibility**: Existing projects that extend `.nuxt/tsconfig.json` will continue to work as before.
+
+3. **Opt-in project references**: New projects or those wanting better type checking can adopt TypeScript's project references feature.
+
+4. **Context-specific type checking**: Each context now has appropriate compiler options and includes/excludes for its specific environment.
+
+5. **New `typescript.nodeTsConfig` option**: You can now customize the TypeScript configuration for Node.js build-time code.
+
+#### Reasons for Change
+
+This change provides several benefits:
+
+1. **Better type safety**: Each context (app, server, build-time) gets appropriate type checking with context-specific globals and APIs.
+2. **Improved IDE experience**: Better IntelliSense and error reporting for different parts of your codebase.
+3. **Cleaner separation**: Server code won't incorrectly suggest client-side APIs and vice versa.
+4. **Performance**: TypeScript can more efficiently check code with properly scoped configurations.
+
+For example, auto-imports are not available in your `nuxt.config.ts` (but previously this was not flagged by TypeScript). And while IDEs recognized the separate context hinted by `tsconfig.json` in your `server/` directory, this was not reflected in type-checking (requiring a separate step).
+
+#### Migration Steps
+
+**No migration is required** - existing projects will continue to work as before.
+
+However, to take advantage of improved type checking, you can opt in to the new project references approach:
+
+1. **Update your root `tsconfig.json`** to use project references:
+
+   ```json
+   {
+     "files": [],
+     "references": [
+       { "path": "./.nuxt/tsconfig.app.json" },
+       { "path": "./.nuxt/tsconfig.server.json" },
+       { "path": "./.nuxt/tsconfig.shared.json" },
+       { "path": "./.nuxt/tsconfig.node.json" }
+     ]
+   }
+   ```
+
+2. **Remove any manual server `tsconfig.json`** files (like `server/tsconfig.json`) that extended `.nuxt/tsconfig.server.json`.
+
+3. **Update your type checking scripts** to use the build flag for project references:
+
+   ```diff
+   - "typecheck": "nuxt prepare && vue-tsc --noEmit"
+   + "typecheck": "nuxt prepare && vue-tsc -b --noEmit"
+   ```
+
+4. **Configure Node.js TypeScript options** if needed:
+   <!-- @case-police-ignore tsConfig -->
+
+   ```ts
+   export default defineNuxtConfig({
+     typescript: {
+       // Customize app/server TypeScript config
+       tsConfig: {
+         compilerOptions: {
+           strict: true
+         }
+       },
+       // Customize build-time TypeScript config  
+       nodeTsConfig: {
+         compilerOptions: {
+           strict: true
+         }
+       }
+     }
+   })
+   ```
+
+5. **Update any CI/build scripts** that run TypeScript checking to ensure they use the new project references approach.
+
+The new configuration provides better type safety and IntelliSense for projects that opt in, while maintaining full backward compatibility for existing setups.
+
 ### Removal of Experimental Features
 
 🚦 **Impact Level**: Minimal
@@ -997,6 +1179,44 @@ These options have been set to their current values for some time and we do not
 
 * `respectNoSSRHeader`is implementable in user-land with [server middleware](https://github.com/nuxt/nuxt/blob/c660b39447f0d5b8790c0826092638d321cd6821/packages/nuxt/src/core/runtime/nitro/no-ssr.ts#L8-L9)
 
+### Removal of Top-Level `generate` Configuration
+
+🚦 **Impact Level**: Minimal
+
+#### What Changed
+
+The top-level `generate` configuration option is no longer available in Nuxt 4. This includes all of its properties:
+
+* `generate.exclude` - for excluding routes from prerendering
+* `generate.routes` - for specifying routes to prerender
+
+#### Reasons for Change
+
+The top level `generate` configuration was a holdover from Nuxt 2. We've supported `nitro.prerender` for a while now, and it is the preferred way to configure prerendering in Nuxt 3+.
+
+#### Migration Steps
+
+Replace `generate` configuration with the corresponding `nitro.prerender` options:
+
+```diff
+export default defineNuxtConfig({
+- generate: {
+-   exclude: ['/admin', '/private'],
+-   routes: ['/sitemap.xml', '/robots.txt']
+- }
++ nitro: {
++   prerender: {
++     ignore: ['/admin', '/private'],
++     routes: ['/sitemap.xml', '/robots.txt']
++   }
++ }
+})
+```
+
+::read-more{to="https://nitro.build/config#prerender"}
+Read more about Nitro's prerender configuration options.
+::
+
 ## Nuxt 2 vs. Nuxt 3+
 
 In the table below, there is a quick comparison between 3 versions of Nuxt:

package/2.guide/0.index.md

@@ -19,4 +19,7 @@ surround: false
   ::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-square-check" title="Best Practices" to="/docs/guide/best-practices"}
+  Learn about best practices when developing with Nuxt
+  ::
 ::

package/2.guide/1.concepts/3.rendering.md

@@ -70,7 +70,7 @@ Out of the box, a traditional Vue.js application is rendered in the browser (or
 
 **Benefits of client-side rendering:**
 - **Development speed**: When working entirely on the client-side, we don't have to worry about the server compatibility of the code, for example, by using browser-only APIs like the `window` object.
-- **Cheaper:** Running a server adds a cost of infrastructure as you would need to run on a platform that supports JavaScript. We can host Client-only applications on any static server with HTML, CSS, and JavaScript files.
+- **Cheaper:** Running a server adds a cost of infrastructure as you would need to run on a platform that supports JavaScript. We can host client-only applications on any static server with HTML, CSS, and JavaScript files.
 - **Offline:** Because code entirely runs in the browser, it can nicely keep working while the internet is unavailable.
 
 **Downsides of client-side rendering:**

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

@@ -79,7 +79,7 @@ const MyButton = resolveComponent('MyButton')
 ```
 
 ::important
-If you are using `resolveComponent` to handle dynamic components, make sure not to insert anything but the name of the component, which must be a literal string and not be or contain a variable. The string is statically analyzed at compilation step.
+If you are using `resolveComponent` to handle dynamic components, make sure not to insert anything but the name of the component, which must be a literal string and not be or contain a variable. The string is statically analyzed at the compilation step.
 ::
 
 :video-accordion{title="Watch Daniel Roe's short video about resolveComponent()" videoId="4kq8E5IUM2U"}
@@ -187,7 +187,7 @@ Hydrates the component after a specified interaction (e.g., click, mouseover).
 </template>
 ```
 
-If you do not pass an event or list of events, it defaults to hydrating on `pointerenter` and `focus`.
+If you do not pass an event or list of events, it defaults to hydrating on `pointerenter`, `click` and `focus`.
 
 ::note
 Under the hood, this uses Vue's built-in [`hydrateOnInteraction` strategy](https://vuejs.org/guide/components/async.html#hydrate-on-interaction).

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

@@ -377,7 +377,7 @@ Learn more about `<NuxtLink>` usage.
 Nuxt allows programmatic navigation through the `navigateTo()` utility method. Using this utility method, you will be able to programmatically navigate the user in your app. This is great for taking input from the user and navigating them dynamically throughout your application. In this example, we have a simple method called `navigate()` that gets called when the user submits a search form.
 
 ::note
-Ensure to always `await` on `navigateTo` or chain its result by returning from functions.
+Make sure to always `await` on `navigateTo` or chain its result by returning from functions.
 ::
 
 ```vue twoslash

package/2.guide/2.directory-structure/2.env.md

@@ -55,6 +55,10 @@ Since `.env` files are not used in production, you must explicitly set environme
 
 * Many cloud service providers, such as Vercel, Netlify, and AWS, provide interfaces for setting environment variables via their dashboards, CLI tools or configuration files.
 
+::important
+`runtimeConfig` [won't pick up environment variables that don't start with `NUXT_` in production] (https://nuxt.com/docs/guide/going-further/runtime-config#environment-variables).
+::
+
 ## Production Preview
 
 For local production preview purpose, we recommend using [`nuxt preview`](/docs/api/commands/preview) since using this command, the `.env` file will be loaded into `process.env` for convenience. Note that this command requires dependencies to be installed in the package directory.

package/2.guide/3.going-further/1.events.md

@@ -58,25 +58,6 @@ await nuxtApp.callHook('app:user:registered', {
 You can inspect all events using the **Nuxt DevTools** Hooks panel.
 ::
 
-## Augmenting Types
-
-You can augment the types of hooks provided by Nuxt.
-
-```ts
-import { HookResult } from "@nuxt/schema";
-
-declare module '#app' {
-  interface RuntimeNuxtHooks {
-    'your-nuxt-runtime-hook': () => HookResult
-  }
-  interface NuxtHooks {
-    'your-nuxt-hook': () => HookResult
-  }
-}
-
-declare module 'nitropack' {
-  interface NitroRuntimeHooks {
-    'your-nitro-hook': () => void;
-  }
-}
-```
+::read-more{to="/docs/guide/going-further/hooks"}
+Learn more about Nuxt's built-in hooks and how to extend them
+::

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

@@ -74,6 +74,25 @@ export default defineNitroPlugin((nitroApp) => {
 Learn more about available Nitro lifecycle hooks.
 ::
 
-## Additional Hooks
+## Adding Custom Hooks
 
-Learn more about creating custom hooks in the [Events section](/docs/guide/going-further/events).
+You can define your own custom hooks support by extending Nuxt's hook interfaces.
+
+```ts
+import { HookResult } from "@nuxt/schema";
+
+declare module '#app' {
+  interface RuntimeNuxtHooks {
+    'your-nuxt-runtime-hook': () => HookResult
+  }
+  interface NuxtHooks {
+    'your-nuxt-hook': () => HookResult
+  }
+}
+
+declare module 'nitropack' {
+  interface NitroRuntimeHooks {
+    'your-nitro-hook': () => void;
+  }
+}
+```