@nuxt/docs 4.0.0-rc.0 → 4.0.1

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.

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:
 
@@ -409,7 +409,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

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

@@ -34,76 +34,37 @@ bun x nuxt upgrade
 
 To use the latest Nuxt build and test features before their release, read about the [nightly release channel](/docs/guide/going-further/nightly-release-channel) guide.
 
-::warning
-The nightly release channel `latest` tag is currently tracking the Nuxt v4 branch, meaning that it is particularly likely to have breaking changes right now — be careful! You can opt in to the 3.x branch nightly releases with `"nuxt": "npm:nuxt-nightly@3x"`.
-::
-
-## Testing Nuxt 4
+## Migrating to Nuxt 4
 
-Nuxt 4 is **scheduled for release in Q2 2025**. It will include all the features currently available through `compatibilityVersion: 4`.
+Nuxt 4 includes significant improvements and changes. This guide will help you migrate your existing Nuxt 3 application to Nuxt 4.
 
-Until the release, it is possible to test many of Nuxt 4's breaking changes from Nuxt version 3.12+.
+First, upgrade to Nuxt 4:
 
-:video-accordion{title="Watch a video from Alexander Lichter showing how to opt in to Nuxt 4's breaking changes already" videoId="r4wFKlcJK6c"}
+::code-group{sync="pm"}
 
-### Opting in to Nuxt 4
+```bash [npm]
+npm install nuxt@^4.0.0
+```
 
-First, upgrade Nuxt to the [latest release](https://github.com/nuxt/nuxt/releases).
+```bash [yarn]
+yarn add nuxt@^4.0.0
+```
 
-Then you can set your `compatibilityVersion` to match Nuxt 4 behavior:
+```bash [pnpm]
+pnpm add nuxt@^4.0.0
+```
 
-::code-collapse
-```ts twoslash [nuxt.config.ts]
-export default defineNuxtConfig({
-  future: {
-    compatibilityVersion: 4,
-  },
-  // To re-enable _all_ Nuxt v3 behavior, set the following options:
-  // srcDir: '.',
-  // dir: {
-  //   app: 'app'
-  // },
-  // experimental: {
-  //   scanPageMeta: 'after-resolve',
-  //   sharedPrerenderData: false,
-  //   compileTemplate: true,
-  //   resetAsyncDataToUndefined: true,
-  //   templateUtils: true,
-  //   relativeWatchPaths: true,
-  //   normalizeComponentNames: false,
-  //   spaLoadingTemplateLocation: 'within',
-  //   parseErrorData: false,
-  //   pendingWhenIdle: true,
-  //   alwaysRunFetchOnKeyChange: true,
-  //   defaults: {
-  //     useAsyncData: {
-  //       deep: true
-  //     }
-  //   }
-  // },
-  // features: {
-  //   inlineStyles: true
-  // },
-  // unhead: {
-  //   renderSSRHeadOptions: {
-  //     omitLineBreaks: false
-  //   }
-  // }
-})
+```bash [bun]
+bun add nuxt@^4.0.0
 ```
-::
 
-::note
-For now, you need to define the compatibility version in each layer that opts into Nuxt 4 behavior. This will not be required after Nuxt 4 is released.
 ::
 
-When you set your `compatibilityVersion` to `4`, defaults throughout your Nuxt configuration will change to opt in to Nuxt v4 behavior, but you can granularly re-enable Nuxt v3 behavior when testing, following the commented out lines above. Please file issues if so, so that we can address them in Nuxt or in the ecosystem.
+After upgrading, most Nuxt 4 behaviors are now the default. However, some features can still be configured if you need to maintain backward compatibility during your migration.
 
-Breaking or significant changes will be noted here along with migration steps for backward/forward compatibility.
+The following sections detail the key changes and migrations needed when upgrading to Nuxt 4.
 
-::note
-This section is subject to change until the final release, so please check back here regularly if you are testing Nuxt 4 using `compatibilityVersion: 4`.
-::
+Breaking or significant changes are documented below along with migration steps and available configuration options.
 
 ### Migrating Using Codemods
 
@@ -179,6 +140,7 @@ layers/
 modules/
 node_modules/
 public/
+shared/
 server/
   api/
   middleware/
@@ -303,6 +265,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
@@ -411,7 +431,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'
@@ -490,16 +510,6 @@ Update your custom `error.vue` to remove any additional parsing of `error.data`:
   </script>
 ```
 
-Alternatively, you can disable this change:
-
-```ts twoslash [nuxt.config.ts]
-export default defineNuxtConfig({
-  experimental: {
-    parseErrorData: false
-  },
-})
-```
-
 ### More Granular Inline Styles
 
 🚦 **Impact Level**: Moderate
@@ -697,21 +707,6 @@ If you provide a custom `default` value for `useAsyncData`, this will now be use
 
 Often users set an appropriately empty value, such as an empty array, to avoid the need to check for `null`/`undefined` when iterating over it. This should be respected when resetting/clearing the data.
 
-#### Migration Steps
-
-If you encounter any issues you can revert back to the previous behavior, for now, with:
-
-```ts twoslash [nuxt.config.ts]
-// @errors: 2353
-export default defineNuxtConfig({
-  experimental: {
-    resetAsyncDataToUndefined: true,
-  }
-})
-```
-
-Please report an issue if you are doing so, as we do not plan to keep this as configurable.
-
 ### Alignment of `pending` value in `useAsyncData` and `useFetch`
 
 🚦 **Impact Level**: Medium
@@ -784,7 +779,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:
@@ -980,7 +975,41 @@ const importName = genSafeVariableName
 You can automate this step by running `npx codemod@latest nuxt/4/template-compilation-changes`
 ::
 
-### TypeScript Configuration 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
 
@@ -1127,7 +1156,7 @@ export default defineNuxtConfig({
 })
 ```
 
-::read-more{to="https://nitro.build/config/#prerender"}
+::read-more{to="https://nitro.build/config#prerender"}
 Read more about Nitro's prerender configuration options.
 ::
 

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.app/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"}

package/2.guide/2.directory-structure/1.app/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/1.shared.md

@@ -15,12 +15,6 @@ The `shared/` directory is available in Nuxt v3.14+.
 Code in the `shared/` directory cannot import any Vue or Nitro code.
 ::
 
-::warning
-Auto-imports are not enabled by default in Nuxt v3 to prevent breaking changes in existing projects.
-
-To use these auto-imported utils and types, you must first [set `future.compatibilityVersion: 4` in your `nuxt.config.ts`](/docs/getting-started/upgrade#opting-in-to-nuxt-4).
-::
-
 :video-accordion{title="Watch a video from Vue School on sharing utils and types between app and server" videoId="nnAR-MO3q5M"}
 
 ## Usage

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/types' {
-  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/1.experimental-features.md

@@ -3,7 +3,7 @@ title: "Experimental Features"
 description: "Enable Nuxt experimental features to unlock new possibilities."
 ---
 
-The Nuxt experimental features can be enabled in the Nuxt configuration file.
+Nuxt includes experimental features that you can enable in your configuration file.
 
 Internally, Nuxt uses `@nuxt/schema` to define these experimental features. You can refer to the [API documentation](/docs/api/configuration/nuxt-config#experimental) or the [source code](https://github.com/nuxt/nuxt/blob/main/packages/schema/src/config/experimental.ts) for more information.
 
@@ -284,14 +284,14 @@ export default defineNuxtConfig({
 
 ## sharedPrerenderData
 
-Enabling this feature automatically shares payload *data* between pages that are prerendered. This can result
-in a significant performance improvement when prerendering sites that use `useAsyncData` or `useFetch` and
-fetch the same data in different pages.
+Nuxt automatically shares payload *data* between pages that are prerendered. This can result in a significant performance improvement when prerendering sites that use `useAsyncData` or `useFetch` and fetch the same data in different pages.
+
+You can disable this feature if needed.
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   experimental: {
-    sharedPrerenderData: true
+    sharedPrerenderData: false
   }
 })
 ```
@@ -332,11 +332,11 @@ globalThis.Buffer = globalThis.Buffer || Buffer
 
 ## scanPageMeta
 
-This option allows exposing some route metadata defined in `definePageMeta` at build-time to modules (specifically `alias`, `name`, `path`, `redirect`, `props` and `middleware`).
+Nuxt exposing some route metadata defined in `definePageMeta` at build-time to modules (specifically `alias`, `name`, `path`, `redirect`, `props` and `middleware`).
 
 This only works with static or strings/arrays rather than variables or conditional assignment. See [original issue](https://github.com/nuxt/nuxt/issues/24770) for more information and context.
 
-It is also possible to scan page metadata only after all routes have been registered in `pages:extend`. Then another hook, `pages:resolved` will be called. To enable this behavior, set `scanPageMeta: 'after-resolve'`.
+By default page metadata is only scanned after all routes have been registered in `pages:extend`. Then another hook, `pages:resolved` will be called.
 
 You can disable this feature if it causes issues in your project.
 
@@ -427,13 +427,14 @@ This allows modules to access additional metadata from the page metadata in the
 
 ## normalizeComponentNames
 
-Ensure that auto-generated Vue component names match the full component name
-you would use to auto-import the component.
+Nuxt updates auto-generated Vue component names to match the full component name you would use to auto-import the component.
+
+If you encounter issues, you can disable this feature.
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   experimental: {
-    normalizeComponentNames: true
+    normalizeComponentNames: false
   }
 })
 ```