@nuxt/docs 4.1.3 → 4.2.1

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

@@ -75,5 +75,5 @@ Note that for a purely static site, it is not possible to set runtime configurat
 
 ::note
 If you want to use environment variables set at build time but do not care about updating these down the line (or only need to update them reactively _within_ your app) then `appConfig` may be a better choice. You can define `appConfig` both within your `nuxt.config` (using environment variables) and also within an `~/app.config.ts` file in your project.
-:read-more{to="/docs/4.x/guide/directory-structure/app-config"}
+:read-more{to="/docs/4.x/guide/directory-structure/app/app-config"}
 ::

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

@@ -1,13 +1,13 @@
 ---
 title: "tsconfig.json"
-description: "Nuxt generates multiple TypeScript configuration files with sensible defaults and your aliases."
+description: "Learn how Nuxt manages TypeScript configuration across different parts of your project."
 head.title: "tsconfig.json"
 navigation.icon: i-vscode-icons-file-type-tsconfig
 ---
 
-Nuxt [automatically generates](/docs/4.x/guide/concepts/typescript) multiple TypeScript configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, `.nuxt/tsconfig.node.json` and `.nuxt/tsconfig.shared.json`) with the resolved aliases you are using in your Nuxt project, as well as with other sensible defaults.
+Nuxt [automatically generates](/docs/4.x/guide/concepts/typescript#auto-generated-types) multiple TypeScript configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, `.nuxt/tsconfig.node.json` and `.nuxt/tsconfig.shared.json`) that include recommended basic TypeScript configuration for your project, references to [auto-imports](/docs/4.x/guide/concepts/auto-imports), [API route types](/docs/4.x/guide/concepts/server-engine#typed-api-routes), path aliases, and more.
 
-You can benefit from this by creating a `tsconfig.json` in the root of your project with the following content:
+Your Nuxt project should include the following `tsconfig.json` file at the root of the project:
 
 ```json [tsconfig.json]
 {
@@ -29,10 +29,41 @@ You can benefit from this by creating a `tsconfig.json` in the root of your proj
 }
 ```
 
-::note
-As you need to, you can customize the contents of this file. However, it is recommended that you don't overwrite `target`, `module` and `moduleResolution`.
+::warning
+We do not recommend modifying the contents of this file directly, as doing so could overwrite important settings that Nuxt or other modules rely on. Instead, extend it via `nuxt.config.ts`.
 ::
 
-::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/4.x/api/nuxt-config#alias) property within your `nuxt.config`, where they will get picked up and added to the auto-generated `tsconfig`.
+::read-more{to="/docs/4.x/guide/concepts/typescript#project-references"}
+Read more about the different type contexts of a Nuxt project here.
 ::
+
+## Extending TypeScript Configuration
+
+You can customize the TypeScript configuration of your Nuxt project for each context (`app`, `shared`, `node`, 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: {
+      // ...
+    },
+    // customize tsconfig.shared.json
+    sharedTsConfig: {
+      // ...
+    },
+    // customize tsconfig.node.json
+    nodeTsConfig: {
+      // ...
+    },
+  },
+  nitro: {
+    typescript: {
+      // customize tsconfig.server.json
+      tsConfig: {
+        // ...
+      },
+    },
+  },
+})
+```

package/2.guide/2.concepts/1.auto-imports.md

@@ -3,7 +3,7 @@ title: Auto-imports
 description: "Nuxt auto-imports components, composables, helper functions and Vue APIs."
 ---
 
-Nuxt auto-imports components, composables and [Vue.js APIs](https://vuejs.org/api) to use across your application without explicitly importing them.
+Nuxt auto-imports components, composables and [Vue.js APIs](https://vuejs.org/api/) to use across your application without explicitly importing them.
 
 ```vue twoslash [app/app.vue]
 <script setup lang="ts">
@@ -109,7 +109,7 @@ Nuxt directly auto-imports files created in defined directories:
 
 ::warning
 **Auto-imported `ref` and `computed` won't be unwrapped in a component `<template>`.** :br
-This is due to how Vue works with refs that aren't top-level to the template. You can read more about it [in the Vue documentation](https://vuejs.org/guide/essentials/reactivity-fundamentals.html#caveat-when-unwrapping-in-templates).
+This is due to how Vue works with refs that aren't top-level to the template. You can read more about it [in the Vue documentation](https://vuejs.org/guide/essentials/reactivity-fundamentals#caveat-when-unwrapping-in-templates).
 ::
 
 ### Explicit Imports

package/2.guide/2.concepts/10.nuxt-lifecycle.md

@@ -40,13 +40,13 @@ The Vue and Nuxt instances are created first. Afterward, Nuxt executes its serve
 - Built-in plugins, such as Vue Router and `unhead`.
 - Custom plugins located in the `app/plugins/` directory, including those without a suffix (e.g., `myPlugin.ts`) and those with the `.server` suffix (e.g., `myServerPlugin.server.ts`).
 
-Plugins execute in a specific order and may have dependencies on one another. For more details, including execution order and parallelism, refer to the [Plugins documentation](/docs/4.x/guide/directory-structure/plugins).
+Plugins execute in a specific order and may have dependencies on one another. For more details, including execution order and parallelism, refer to the [Plugins documentation](/docs/4.x/guide/directory-structure/app/plugins).
 
 ::callout{icon="i-lucide-lightbulb"}
 After this step, Nuxt calls the [`app:created`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
 ::
 
-:read-more{to="/docs/4.x/guide/directory-structure/plugins"}
+:read-more{to="/docs/4.x/guide/directory-structure/app/plugins"}
 
 ### Step 4: Route Validation
 
@@ -120,7 +120,7 @@ Custom plugins in the `app/plugins/` directory, such as those without a suffix (
 After this step, Nuxt calls the [`app:created`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook, which can be used to execute additional logic.
 ::
 
-:read-more{to="/docs/4.x/guide/directory-structure/plugins"}
+:read-more{to="/docs/4.x/guide/directory-structure/app/plugins"}
 
 ### Step 2: Route Validation
 

package/2.guide/2.concepts/2.vuejs-development.md

@@ -21,7 +21,7 @@ We chose to build Nuxt on top of Vue for these reasons:
 
 ### Single File Components
 
-[Vue’s single-file components](https://vuejs.org/guide/scaling-up/sfc.html) (SFC or `*.vue` files) encapsulate the markup (`<template>`), logic (`<script>`) and styling (`<style>`) of a Vue component. Nuxt provides a zero-config experience for SFCs with [Hot Module Replacement](https://vite.dev/guide/features.html#hot-module-replacement) that offers a seamless developer experience.
+[Vue’s single-file components](https://vuejs.org/guide/scaling-up/sfc) (SFC or `*.vue` files) encapsulate the markup (`<template>`), logic (`<script>`) and styling (`<style>`) of a Vue component. Nuxt provides a zero-config experience for SFCs with [Hot Module Replacement](https://vite.dev/guide/features#hot-module-replacement) that offers a seamless developer experience.
 
 ### Auto-imports
 
@@ -78,7 +78,7 @@ export default {
 </script>
 ```
 
-The [Composition API](https://vuejs.org/guide/extras/composition-api-faq.html) introduced in Vue 3 is not a replacement of the Options API, but it enables better logic reuse throughout an application, and is a more natural way to group code by concern in complex components.
+The [Composition API](https://vuejs.org/guide/extras/composition-api-faq) introduced in Vue 3 is not a replacement of the Options API, but it enables better logic reuse throughout an application, and is a more natural way to group code by concern in complex components.
 
 Used with the `setup` keyword in the `<script>` definition, here is the above component rewritten with Composition API and Nuxt 3’s auto-imported Reactivity APIs:
 
@@ -91,7 +91,7 @@ const increment = () => count.value++
 
 The goal of Nuxt is to provide a great developer experience around the Composition API.
 
-- Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core.html) from Vue and Nuxt [built-in composables](/docs/4.x/api/composables/use-async-data).
+- Use auto-imported [Reactivity functions](https://vuejs.org/api/reactivity-core) from Vue and Nuxt [built-in composables](/docs/4.x/api/composables/use-async-data).
 - Write your own auto-imported reusable functions in the [`app/composables/` directory](/docs/4.x/guide/directory-structure/app/composables).
 
 ### TypeScript Support

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

@@ -44,7 +44,7 @@ const handleClick = () => {
 
 On the initial request, the `counter` ref is initialized in the server since it is rendered inside the `<p>` tag. The contents of `handleClick` is never executed here. During hydration in the browser, the `counter` ref is re-initialized. The `handleClick` finally binds itself to the button; Therefore it is reasonable to deduce that the body of `handleClick` will always run in a browser environment.
 
-[Middlewares](/docs/4.x/guide/directory-structure/app/middleware) and [pages](/docs/4.x/guide/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/4.x/guide/directory-structure/plugins) can be rendered on the server or client or both. [Components](/docs/4.x/guide/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/4.x/guide/directory-structure/app/composables) and [utilities](/docs/4.x/guide/directory-structure/app/utils) are rendered based on the context of their usage.
+[Middlewares](/docs/4.x/guide/directory-structure/app/middleware) and [pages](/docs/4.x/guide/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/4.x/guide/directory-structure/app/plugins) can be rendered on the server or client or both. [Components](/docs/4.x/guide/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/4.x/guide/directory-structure/app/composables) and [utilities](/docs/4.x/guide/directory-structure/app/utils) are rendered based on the context of their usage.
 
 **Benefits of server-side rendering:**
 - **Performance**: Users can get immediate access to the page's content because browsers can display static content much faster than JavaScript-generated content. At the same time, Nuxt preserves the interactivity of a web application during the hydration process.
@@ -57,7 +57,7 @@ On the initial request, the `counter` ref is initialized in the server since it
 Universal rendering is very versatile and can fit almost any use case, and is especially appropriate for any content-oriented websites: **blogs, marketing websites, portfolios, e-commerce sites, and marketplaces.**
 
 ::tip
-For more examples about writing Vue code without hydration mismatch, see [the Vue docs](https://vuejs.org/guide/scaling-up/ssr.html#hydration-mismatch).
+For more examples about writing Vue code without hydration mismatch, see [the Vue docs](https://vuejs.org/guide/scaling-up/ssr#hydration-mismatch).
 ::
 
 ::important
@@ -225,8 +225,8 @@ Edge-side rendering is possible thanks to [Nitro](https://nitro.build/), the [se
 
 The current platforms where you can leverage ESR are:
 - [Cloudflare Pages](https://pages.cloudflare.com) with zero configuration using the git integration and the `nuxt build` command
-- [Vercel Edge Functions](https://vercel.com/features/edge-functions) using the `nuxt build` command and `NITRO_PRESET=vercel-edge` environment variable
-- [Netlify Edge Functions](https://www.netlify.com/products/#netlify-edge-functions) using the `nuxt build` command and `NITRO_PRESET=netlify-edge` environment variable
+- [Vercel Cloud](https://vercel.com/home) using the `nuxt build` command and `NITRO_PRESET=vercel-edge` environment variable
+- [Netlify Edge Functions](https://www.netlify.com/platform/#netlify-edge-functions) using the `nuxt build` command and `NITRO_PRESET=netlify-edge` environment variable
 
 Note that **Hybrid Rendering** can be used when using Edge-Side Rendering with route rules.
 

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

@@ -31,7 +31,7 @@ export { a }
 ```
 
 Before ECMAScript Modules (ESM) became a standard (it took more than 10 years!), tooling like
-[webpack](https://webpack.js.org/guides/ecma-script-modules) and even languages like TypeScript started supporting so-called **ESM syntax**.
+[webpack](https://webpack.js.org/guides/ecma-script-modules/) and even languages like TypeScript started supporting so-called **ESM syntax**.
 However, there are some key differences with actual spec; here's [a helpful explainer](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/).
 
 ### What is 'Native' ESM?
@@ -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')`.
 
@@ -157,7 +161,7 @@ const pkg = require('cjs-pkg')
 console.log(pkg) // { test: 123 }
 ```
 
-[Node.js in native ESM mode](https://nodejs.org/api/esm.html#interoperability-with-commonjs), [typescript with `esModuleInterop` enabled](https://www.typescriptlang.org/tsconfig#esModuleInterop) and bundlers such as webpack, provide a compatibility mechanism so that we can default import such library.
+[Node.js in native ESM mode](https://nodejs.org/api/esm.html#interoperability-with-commonjs), [typescript with `esModuleInterop` enabled](https://www.typescriptlang.org/tsconfig/#esModuleInterop) and bundlers such as webpack, provide a compatibility mechanism so that we can default import such library.
 This mechanism is often referred to as "interop require default":
 
 ```js

package/2.guide/2.concepts/8.typescript.md

@@ -47,56 +47,37 @@ export default defineNuxtConfig({
 
 ## Auto-generated Types
 
-When you run `nuxt dev` or `nuxt build`, Nuxt generates the following files for IDE type support (and type checking):
+Nuxt projects rely on auto-generated types to work properly. These types are stored in the [`.nuxt`](/docs/4.x/guide/directory-structure/nuxt) directory and are generated when you run the dev server or build your application. You can also generate these files manually by running `nuxt prepare`.
 
-### `.nuxt/nuxt.d.ts`
+The generated `tsconfig.json` files inside the [`.nuxt`](/docs/4.x/guide/directory-structure/nuxt) directory include **recommended basic TypeScript configuration** for your project, references to [auto-imports](/docs/4.x/guide/concepts/auto-imports), [API route types](/docs/4.x/guide/concepts/server-engine#typed-api-routes), path aliases like `#imports`, `~/file`, or `#build/file`, and more.
 
-This file contains the types of any modules you are using, as well as the key types that Nuxt requires. Your IDE should recognize these types automatically.
-
-Some of the references in the file are to files that are only generated within your `buildDir` (`.nuxt`) and therefore for full typings, you will need to run `nuxt dev` or `nuxt build`.
-
-### `.nuxt/tsconfig.app.json`
-
-This file contains the recommended basic TypeScript configuration for your project, including resolved aliases injected by Nuxt or modules you are using, so you can get full type support and path auto-complete for aliases like `~/file` or `#build/file`.
-
-::note
-Consider using the `imports` section of [nuxt.config](/docs/4.x/api/nuxt-config#imports) to include directories beyond the default ones. This can be useful for auto-importing types which you're using across your app.
+::warning
+Nuxt relies on this configuration, and [Nuxt Modules](/docs/4.x/guide/going-further/modules) can extend it as well. For this reason, it is not recommended to modify your `tsconfig.json` file directly, as doing so could overwrite important settings. Instead, extend it via `nuxt.config.ts`. [Learn more about extending the configuration here](/docs/4.x/guide/directory-structure/tsconfig).
 ::
 
-[Read more about how to extend this configuration](/docs/4.x/guide/directory-structure/tsconfig).
-
 ::tip{icon="i-lucide-video" to="https://youtu.be/umLI7SlPygY" target="_blank"}
 Watch a video from Daniel Roe explaining built-in Nuxt aliases.
 ::
 
-::note
-Nitro also [auto-generates types](/docs/4.x/guide/concepts/server-engine#typed-api-routes) for API routes. Plus, Nuxt also generates types for globally available components and [auto-imports from your composables](/docs/4.x/guide/directory-structure/app/composables), plus other core functionality.
-::
-
-::note
-For backward compatibility, Nuxt still generates `./.nuxt/tsconfig.json`. However, we recommend using [TypeScript project references](/docs/4.x/guide/directory-structure/tsconfig) with the new configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, etc.) for better type safety and performance.
-
-If you do extend from `./.nuxt/tsconfig.json`, keep in mind that all options will be overwritten by those defined in your `tsconfig.json`. Overwriting options such as `"compilerOptions.paths"` with your own configuration will lead TypeScript to not factor in the module resolutions, which can cause module resolutions such as `#imports` to not be recognized.
-
-In case you need to extend options further, you can use the [`alias` property](/docs/4.x/api/nuxt-config#alias) within your `nuxt.config`. Nuxt will pick them up and extend the generated TypeScript configurations accordingly.
-::
-
 ## Project References
 
 Nuxt uses [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html) to improve type-checking performance and provide better IDE support. This feature allows TypeScript to break up your codebase into smaller, more manageable pieces.
 
 ### How Nuxt Uses Project References
 
-When you run `nuxt dev` or `nuxt build`, Nuxt will generate multiple `tsconfig.json` files for different parts of your application.
+When you run `nuxt dev`, `nuxt build` or `nuxt prepare`, Nuxt will generate multiple `tsconfig.json` files for different parts of your application.
 
-- **`.nuxt/tsconfig.app.json`** - Configuration for your application code
-- **`.nuxt/tsconfig.node.json`** - Configuration for your `nuxt.config` and modules
+- **`.nuxt/tsconfig.app.json`** - Configuration for your application code within the `app/` directory
+- **`.nuxt/tsconfig.node.json`** - Configuration for your `nuxt.config.ts` and files outside the other contexts
 - **`.nuxt/tsconfig.server.json`** - Configuration for server-side code (when applicable)
 - **`.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
 
 Each of these files is configured to reference the appropriate dependencies and provide optimal type-checking for their specific context.
 
+::note
+For backward compatibility, Nuxt still generates `.nuxt/tsconfig.json`. However, we recommend using [TypeScript project references](/docs/4.x/guide/directory-structure/tsconfig) with the new configuration files (`.nuxt/tsconfig.app.json`, `.nuxt/tsconfig.server.json`, etc.) for better type safety and performance. This legacy file will be removed in a future version of Nuxt.
+::
+
 ### Benefits of Project References
 
 - **Faster builds**: TypeScript can skip rebuilding unchanged projects
@@ -104,13 +85,9 @@ Each of these files is configured to reference the appropriate dependencies and
 - **Isolated compilation**: Errors in one part of your application don't prevent compilation of other parts
 - **Clearer dependency management**: Each project explicitly declares its dependencies
 
-::note
-The project reference setup is handled automatically by Nuxt. You typically don't need to modify these configurations manually, but understanding how they work can help you troubleshoot type-checking issues.
-::
-
 ### Augmenting Types with Project References
 
-Since the project is divided into **multiple type contexts**, it's important to **augment types within the correct context** to ensure they are properly recognized.
+Since the project is divided into **multiple type contexts**, it's important to **augment types within the correct context** to ensure they're properly recognized. TypeScript will not recognize augmentations placed outside these directories unless they are explicitly included in the appropriate context.
 
 For example, if you want to augment types for the `app` context, the augmentation file should be placed in the `app/` directory.
 
@@ -118,15 +95,15 @@ Similarly:
 - For the `server` context, place the augmentation file in the `server/` directory.
 - For types that are **shared between the app and server**, place the file in the `shared/` directory.
 
-::warning
-Augmenting types outside of these directories will not be recognized by TypeScript.
+::read-more{to="/docs/4.x/guide/going-further/modules#extending-tsconfigjson"}
+Read more about augmenting specific type contexts from **files outside those contexts** in the Module Author Guide.
 ::
 
 ## Strict Checks
 
 TypeScript comes with certain checks to give you more safety and analysis of your program.
 
-[Strict checks](https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html#getting-stricter-checks) are enabled by default in Nuxt to give you greater type safety.
+[Strict checks](https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html#getting-stricter-checks) are enabled by default in Nuxt when the [`typescript.typeCheck`](/docs/4.x/guide/concepts/typescript#type-checking) option is enabled to give you greater type safety.
 
 If you are currently converting your codebase to TypeScript, you may want to temporarily disable strict checks by setting `strict` to `false` in your `nuxt.config`:
 

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) 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#customizing-the-config). 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

@@ -5,7 +5,7 @@ description: "Enable Nuxt experimental features to unlock new possibilities."
 
 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/4.x/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.
+Internally, Nuxt uses `@nuxt/schema` to define these experimental features. You can refer to the [API documentation](/docs/4.x/guide/going-further/experimental-features) or the [source code](https://github.com/nuxt/nuxt/blob/main/packages/schema/src/config/experimental.ts) for more information.
 
 ::note
 Note that these features are experimental and could be removed or modified in the future.
@@ -87,6 +87,44 @@ export default defineNuxtConfig({
 This feature will likely be removed in a near future.
 ::
 
+## 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.
@@ -252,7 +290,7 @@ export default defineNuxtConfig({
 
 :link-example{to="https://stackblitz.com/edit/nuxt-view-transitions?file=app.vue" target="_blank"}
 
-::read-more{icon="i-simple-icons-mdnwebdocs" to="https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API" target="_blank"}
+::read-more{icon="i-simple-icons-mdnwebdocs" to="https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API" target="_blank"}
 Read more about the **View Transition API**.
 ::
 
@@ -367,12 +405,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 })
 })
 ```
 
@@ -831,3 +869,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/1.features.md

@@ -61,9 +61,21 @@ There is also a `future` namespace for early opting-in to new features that will
 
 ### compatibilityVersion
 
-This is used for enabling early access to Nuxt features or flags.
+This enables early access to Nuxt features or flags.
 
-It is not configurable yet in Nuxt 4, but once we begin merging breaking changes for v5, it will be possible to enable it.
+Setting `compatibilityVersion` to `5` changes defaults throughout your Nuxt configuration to opt in to Nuxt v5 behaviour, including enabling the [Vite Environment API](/docs/4.x/guide/going-further/experimental-features#viteenvironmentapi).
+
+```ts
+export default defineNuxtConfig({
+  future: {
+    compatibilityVersion: 5,
+  },
+})
+```
+
+::read-more{to="/docs/4.x/getting-started/upgrade#testing-nuxt-5"}
+Learn more about testing Nuxt 5.
+::
 
 ### multiApp
 
@@ -79,7 +91,7 @@ export default defineNuxtConfig({
 
 ### typescriptBundlerResolution
 
-This enables 'Bundler' module resolution mode for TypeScript, which is the recommended setting for frameworks like Nuxt and [Vite](https://vite.dev/guide/performance.html#reduce-resolve-operations).
+This enables 'Bundler' module resolution mode for TypeScript, which is the recommended setting for frameworks like Nuxt and [Vite](https://vite.dev/guide/performance#reduce-resolve-operations).
 
 It improves type support when using modern libraries with `exports`.
 

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

@@ -30,7 +30,7 @@ Global usage is possible for the browser but not on the server, to avoid sharing
 
 Since [`useNuxtApp`](/docs/4.x/api/composables/use-nuxt-app) throws an exception if context is currently unavailable, if your composable does not always require `nuxtApp`, you can use [`tryUseNuxtApp`](/docs/4.x/api/composables/use-nuxt-app#tryusenuxtapp) instead, which will return `null` instead of throwing an exception.
 
-To extend the `nuxtApp` interface and hook into different stages or access contexts, we can use [Nuxt Plugins](/docs/4.x/guide/directory-structure/plugins).
+To extend the `nuxtApp` interface and hook into different stages or access contexts, we can use [Nuxt Plugins](/docs/4.x/guide/directory-structure/app/plugins).
 
 Check [Nuxt App](/docs/4.x/api/composables/use-nuxt-app) for more information about this interface.
 
@@ -76,6 +76,6 @@ Nuxt builds and bundles project using Node.js but also has a runtime side.
 
 While both areas can be extended, that runtime context is isolated from build-time. Therefore, they are not supposed to share state, code, or context other than runtime configuration!
 
-`nuxt.config` and [Nuxt Modules](/docs/4.x/guide/going-further/modules) can be used to extend the build context, and [Nuxt Plugins](/docs/4.x/guide/directory-structure/plugins) can be used to extend runtime.
+`nuxt.config` and [Nuxt Modules](/docs/4.x/guide/going-further/modules) can be used to extend the build context, and [Nuxt Plugins](/docs/4.x/guide/directory-structure/app/plugins) can be used to extend runtime.
 
 When building an application for production, `nuxt build` will generate a standalone build in the `.output` directory, independent of `nuxt.config` and [Nuxt modules](/docs/4.x/guide/going-further/modules).

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

@@ -39,7 +39,7 @@ Explore all available Nuxt hooks.
 
 ## App Hooks (Runtime)
 
-App hooks can be mainly used by [Nuxt Plugins](/docs/4.x/guide/directory-structure/plugins) to hook into rendering lifecycle but could also be used in Vue composables.
+App hooks can be mainly used by [Nuxt Plugins](/docs/4.x/guide/directory-structure/app/plugins) to hook into rendering lifecycle but could also be used in Vue composables.
 
 ```ts [app/plugins/test.ts]
 export default defineNuxtPlugin((nuxtApp) => {