@nuxt/docs-nightly 4.3.0-29356103.2f7957ac → 4.3.0-29430576.f48ea4c8

package/{2.guide/2.concepts/3.rendering.md → 3.guide/1.concepts/1.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/directory-structure/app/middleware) and [pages](/docs/4.x/directory-structure/app/pages) run in the server and on the client during hydration. [Plugins](/docs/4.x/directory-structure/app/plugins) can be rendered on the server or client or both. [Components](/docs/4.x/directory-structure/app/components) can be forced to run on the client only as well. [Composables](/docs/4.x/directory-structure/app/composables) and [utilities](/docs/4.x/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,33 +225,7 @@ 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.
-
-You can explore open source examples deployed on some of the platform mentioned above:
-::card-group
-  ::card
-  ---
-  icon: i-simple-icons-github
-  title: Nuxt Todos Edge
-  to: https://github.com/atinux/nuxt-todos-edge
-  target: _blank
-  ui.icon.base: text-black dark:text-white
-  ---
-  A todos application with user authentication, SSR and SQLite.
-  ::
-  ::card
-  ---
-  icon: i-simple-icons-github
-  title: Atinotes
-  to: https://github.com/atinux/atinotes
-  target: _blank
-  ui.icon.base: text-black dark:text-white
-  ---
-  An editable website with universal rendering based on Cloudflare KV.
-  ::
-::
-
-<!-- TODO: link to templates with ESR category for examples -->

package/{2.guide/2.concepts/2.vuejs-development.md → 3.guide/1.concepts/10.vuejs-development.md}

@@ -1,6 +1,7 @@
 ---
 title: 'Vue.js Development'
 description: "Nuxt uses Vue.js and adds features such as component auto-imports, file-based routing and composables for an SSR-friendly usage."
+navigation: false
 ---
 
 Nuxt integrates Vue 3, the new major release of Vue that enables new patterns for Nuxt users.
@@ -21,17 +22,17 @@ 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
 
-Every Vue component created in the [`app/components/`](/docs/4.x/guide/directory-structure/app/components) directory of a Nuxt project will be available in your project without having to import it. If a component is not used anywhere, your production’s code will not include it.
+Every Vue component created in the [`app/components/`](/docs/4.x/directory-structure/app/components) directory of a Nuxt project will be available in your project without having to import it. If a component is not used anywhere, your production’s code will not include it.
 
 :read-more{to="/docs/4.x/guide/concepts/auto-imports"}
 
 ### Vue Router
 
-Most applications need multiple pages and a way to navigate between them. This is called **routing**. Nuxt uses an [`app/pages/`](/docs/4.x/guide/directory-structure/app/pages) directory and naming conventions to directly create routes mapped to your files using the official [Vue Router library](https://router.vuejs.org).
+Most applications need multiple pages and a way to navigate between them. This is called **routing**. Nuxt uses an [`app/pages/`](/docs/4.x/directory-structure/app/pages) directory and naming conventions to directly create routes mapped to your files using the official [Vue Router library](https://router.vuejs.org).
 
 :read-more{to="/docs/4.x/getting-started/routing"}
 
@@ -78,7 +79,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,8 +92,8 @@ 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).
-- Write your own auto-imported reusable functions in the [`app/composables/` directory](/docs/4.x/guide/directory-structure/app/composables).
+- 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/directory-structure/app/composables).
 
 ### TypeScript Support
 

package/{2.guide/2.concepts/10.nuxt-lifecycle.md → 3.guide/1.concepts/2.nuxt-lifecycle.md}

@@ -5,15 +5,16 @@ description: "Understanding the lifecycle of Nuxt applications can help you gain
 
 The goal of this chapter is to provide a high-level overview of the different parts of the framework, their execution order, and how they work together.
 
-## Server
+## Server lifecycle
 
 On the server, the following steps are executed for every initial request to your application:
 
-### Step 1: Setup Nitro Server and Nitro Plugins (Once)
+::steps
+### Server plugins :badge[once]{color="info" class="align-middle"}
 
 Nuxt is powered by [Nitro](https://nitro.build/), a modern server engine.
 
-When Nitro starts, it initializes and executes the plugins under the `/server/plugins` directory. These plugins can:
+When Nitro starts, it initializes and executes the plugins under the [`/server/plugins`](/docs/4.x/directory-structure/server#server-plugins) directory. These plugins can:
 - Capture and handle application-wide errors.
 - Register hooks that execute when Nitro shuts down.
 - Register hooks for request lifecycle events, such as modifying responses.
@@ -22,9 +23,9 @@ When Nitro starts, it initializes and executes the plugins under the `/server/pl
 Nitro plugins are executed only once when the server starts. In a serverless environment, the server boots on each incoming request, and so do the Nitro plugins. However, they are not awaited.
 ::
 
-:read-more{to="/docs/4.x/guide/directory-structure/server#server-plugins"}
+:read-more{to="/docs/4.x/directory-structure/server#server-plugins"}
 
-### Step 2: Nitro Server Middleware
+### Server middleware
 
 After initializing the Nitro server, middleware under `server/middleware/` is executed for every request. Middleware can be used for tasks such as authentication, logging, or request transformation.
 
@@ -32,23 +33,23 @@ After initializing the Nitro server, middleware under `server/middleware/` is ex
 Returning a value from middleware will terminate the request and send the returned value as the response. This behavior should generally be avoided to ensure proper request handling!
 ::
 
-:read-more{to="/docs/4.x/guide/directory-structure/server#server-middleware"}
+:read-more{to="/docs/4.x/directory-structure/server#server-middleware"}
 
-### Step 3: Initialize Nuxt and Execute Nuxt App Plugins
+### App plugins
 
-The Vue and Nuxt instances are created first. Afterward, Nuxt executes its server plugins. This includes:
+The Vue and Nuxt instances are created first. Afterward, Nuxt executes its app plugins. This includes:
 - 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/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/directory-structure/app/plugins"}
 
-### Step 4: Route Validation
+### Route validation
 
 After initializing plugins and before executing middleware, Nuxt calls the `validate` method if it is defined in the `definePageMeta` function. The `validate` method, which can be synchronous or asynchronous, is often used to validate dynamic route parameters.
 
@@ -59,7 +60,7 @@ For more information, see the [Route Validation documentation](/docs/4.x/getting
 
 :read-more{to="/docs/4.x/getting-started/routing#route-validation"}
 
-### Step 5: Execute Nuxt App Middleware
+### App middleware
 
 Middleware allows you to run code before navigating to a particular route. It is often used for tasks such as authentication, redirection, or logging.
 
@@ -70,13 +71,13 @@ In Nuxt, there are three types of middleware:
 
 Nuxt executes all global middleware on the initial page load (both on server and client) and then again before any client-side navigation. Named and anonymous middleware are executed only on the routes specified in the middleware property of the page(route) meta defined in the corresponding page components.
 
-For details about each type and examples, see the [Middleware documentation](/docs/4.x/guide/directory-structure/app/middleware).
+For details about each type and examples, see the [Middleware documentation](/docs/4.x/directory-structure/app/middleware).
 
 Any redirection on the server will result in a `Location:` header being sent to the browser; the browser then makes a fresh request to this new location. All application state will be reset when this happens, unless persisted in a cookie.
 
-:read-more{to="/docs/4.x/guide/directory-structure/app/middleware"}
+:read-more{to="/docs/4.x/directory-structure/app/middleware"}
 
-### Step 6: Render Page and Components
+### Page and components
 
 Nuxt renders the page and its components and fetches any required data with `useFetch` and `useAsyncData` during this step. Since there are no dynamic updates and no DOM operations occur on the server, Vue lifecycle hooks such as `onBeforeMount`, `onMounted`, and subsequent hooks are **NOT** executed during SSR.
 
@@ -94,7 +95,7 @@ You should avoid code that produces side effects that need cleanup in root scope
 Watch a video from Daniel Roe explaining Server Rendering and Global State.
 ::
 
-### Step 7: Generate HTML Output
+### HTML Output
 
 After all required data is fetched and the components are rendered, Nuxt combines the rendered components with settings from `unhead` to generate a complete HTML document. This HTML, along with the associated data, is then sent back to the client to complete the SSR process.
 
@@ -106,11 +107,15 @@ After rendering the Vue application to HTML, Nuxt calls the [`app:rendered`](/do
 Before finalizing and sending the HTML, Nitro will call the [`render:html`](/docs/4.x/api/advanced/hooks#nitro-app-hooks-runtime-server-side) hook. This hook allows you to manipulate the generated HTML, such as injecting additional scripts or modifying meta tags.
 ::
 
-## Client (browser)
+::
+
+## Client lifecycle
 
 This part of the lifecycle is fully executed in the browser, no matter which Nuxt mode you've chosen.
 
-### Step 1: Initialize Nuxt and Execute Nuxt App Plugins
+::steps
+
+### App plugins
 
 This step is similar to the server-side execution and includes both built-in and custom plugins.
 
@@ -120,21 +125,21 @@ 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/directory-structure/app/plugins"}
 
-### Step 2: Route Validation
+### Route validation
 
 This step is the same as the server-side execution and includes the `validate` method if defined in the `definePageMeta` function.
 
-### Step 3: Execute Nuxt App Middleware
+### App middleware
 
 Nuxt middleware runs on both the server and the client. If you want certain code to run in specific environments, consider splitting it by using `import.meta.client` for the client and `import.meta.server` for the server.
 
-:read-more{to="/docs/4.x/guide/directory-structure/app/middleware#when-middleware-runs"}
+:read-more{to="/docs/4.x/directory-structure/app/middleware#when-middleware-runs"}
 
-### Step 4: Mount Vue Application and Hydration
+### Mount Vue app and hydrate
 
-Calling `app.mount('#__nuxt')` mounts the Vue application to the DOM. If the application uses SSR or SSG mode, Vue performs a hydration step to make the client-side application interactive. During hydration, Vue recreates the application (excluding [Server Components](/docs/4.x/guide/directory-structure/app/components#server-components)), matches each component to its corresponding DOM nodes, and attaches DOM event listeners.
+Calling `app.mount('#__nuxt')` mounts the Vue application to the DOM. If the application uses SSR or SSG mode, Vue performs a hydration step to make the client-side application interactive. During hydration, Vue recreates the application (excluding [Server Components](/docs/4.x/directory-structure/app/components#server-components)), matches each component to its corresponding DOM nodes, and attaches DOM event listeners.
 
 To ensure proper hydration, it's important to maintain consistency between the data on the server and the client. For API requests, it is recommended to use `useAsyncData`, `useFetch`, or other SSR-friendly composables. These methods ensure that the data fetched on the server side is reused during hydration, avoiding repeated requests. Any new requests should only be triggered after hydration, preventing hydration errors.
 
@@ -146,6 +151,8 @@ Before mounting the Vue application, Nuxt calls the [`app:beforeMount`](/docs/4.
 After mounting the Vue application, Nuxt calls the [`app:mounted`](/docs/4.x/api/advanced/hooks#app-hooks-runtime) hook.
 ::
 
-### Step 5: Vue Lifecycle
+### Vue lifecycle
 
 Unlike on the server, the browser executes the full [Vue lifecycle](https://vuejs.org/guide/essentials/lifecycle).
+
+::

package/{2.guide/2.concepts/1.auto-imports.md → 3.guide/1.concepts/3.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">
@@ -11,7 +11,7 @@ const count = ref(1) // ref is auto-imported
 </script>
 ```
 
-Thanks to its opinionated directory structure, Nuxt can auto-import your [`app/components/`](/docs/4.x/guide/directory-structure/app/components), [`app/composables/`](/docs/4.x/guide/directory-structure/app/composables) and [`app/utils/`](/docs/4.x/guide/directory-structure/app/utils).
+Thanks to its opinionated directory structure, Nuxt can auto-import your [`app/components/`](/docs/4.x/directory-structure/app/components), [`app/composables/`](/docs/4.x/directory-structure/app/composables) and [`app/utils/`](/docs/4.x/directory-structure/app/utils).
 
 Contrary to a classic global declaration, Nuxt preserves typings, IDEs completions and hints, and **only includes what is used in your production code**.
 
@@ -20,7 +20,7 @@ In the docs, every function that is not explicitly imported is auto-imported by
 ::
 
 ::note
-In the [`server`](/docs/4.x/guide/directory-structure/server) directory, Nuxt auto-imports exported functions and variables from `server/utils/`.
+In the [`server`](/docs/4.x/directory-structure/server) directory, Nuxt auto-imports exported functions and variables from `server/utils/`.
 ::
 
 ::note
@@ -101,15 +101,15 @@ export const useMyComposable = () => {
 
 Nuxt directly auto-imports files created in defined directories:
 
-- `app/components/` for [Vue components](/docs/4.x/guide/directory-structure/app/components).
-- `app/composables/` for [Vue composables](/docs/4.x/guide/directory-structure/app/composables).
+- `app/components/` for [Vue components](/docs/4.x/directory-structure/app/components).
+- `app/composables/` for [Vue composables](/docs/4.x/directory-structure/app/composables).
 - `app/utils/` for helper functions and other utilities.
 
 :link-example{to="/docs/4.x/examples/features/auto-imports"}
 
 ::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
@@ -167,7 +167,7 @@ With this configuration:
 
 Nuxt also automatically imports components from your `~/components` directory, although this is configured separately from auto-importing composables and utility functions.
 
-:read-more{to="/docs/4.x/guide/directory-structure/app/components"}
+:read-more{to="/docs/4.x/directory-structure/app/components"}
 
 To disable auto-importing components from your own `~/components` directory, you can set `components.dirs` to an empty array (though note that this will not affect components added by modules).
 

package/{2.guide/2.concepts → 3.guide/1.concepts}/4.server-engine.md

@@ -16,7 +16,7 @@ It is shipped with many features:
 
 ## API Layer
 
-Server [API endpoints](/docs/4.x/guide/directory-structure/server#server-routes) and [Middleware](/docs/4.x/guide/directory-structure/server#server-middleware) are added by Nitro that internally uses [h3](https://github.com/h3js/h3).
+Server [API endpoints](/docs/4.x/directory-structure/server#server-routes) and [Middleware](/docs/4.x/directory-structure/server#server-middleware) are added by Nitro that internally uses [h3](https://github.com/h3js/h3).
 
 Key features include:
 
@@ -26,7 +26,7 @@ Key features include:
 
 Check out [the h3 docs](https://github.com/h3js/h3) for more information.
 
-::read-more{to="/docs/4.x/guide/directory-structure/server#server-routes"}
+::read-more{to="/docs/4.x/directory-structure/server#server-routes"}
 Learn more about the API layer in the `server/` directory.
 ::
 
@@ -53,7 +53,7 @@ Nitro produces a standalone server dist that is independent of `node_modules`.
 
 The server in Nuxt 2 is not standalone and requires part of Nuxt core to be involved by running `nuxt start` (with the [`nuxt-start`](https://www.npmjs.com/package/nuxt-start) or [`nuxt`](https://www.npmjs.com/package/nuxt) distributions) or custom programmatic usage, which is fragile and prone to breakage and not suitable for serverless and service worker environments.
 
-Nuxt generates this dist when running `nuxt build` into a [`.output`](/docs/4.x/guide/directory-structure/output) directory.
+Nuxt generates this dist when running `nuxt build` into a [`.output`](/docs/4.x/directory-structure/output) directory.
 
 The output contains runtime code to run your Nuxt server in any environment (including experimental browser service workers!) and serve your static files, making it a true hybrid framework for the JAMstack. In addition, Nuxt implements a native storage layer, supporting multi-source drivers and local assets.
 

package/{2.guide/2.concepts → 3.guide/1.concepts}/5.modules.md

@@ -17,7 +17,7 @@ Explore Nuxt Modules
 
 ## Add Nuxt Modules
 
-Once you have installed the modules you can add them to your [`nuxt.config.ts`](/docs/4.x/guide/directory-structure/nuxt-config) file under the `modules` property. Module developers usually provide additional steps and details for usage.
+Once you have installed the modules you can add them to your [`nuxt.config.ts`](/docs/4.x/directory-structure/nuxt-config) file under the `modules` property. Module developers usually provide additional steps and details for usage.
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
@@ -45,4 +45,4 @@ Nuxt modules are now build-time-only, and the `buildModules` property used in Nu
 
 Everyone has the opportunity to develop modules and we cannot wait to see what you will build.
 
-:read-more{to="/docs/4.x/guide/going-further/modules" title="Module Author Guide"}
+:read-more{to="/docs/4.x/guide/modules" title="Module Author Guide"}

package/{2.guide/2.concepts → 3.guide/1.concepts}/7.esm.md

@@ -1,6 +1,7 @@
 ---
 title: 'ES Modules'
 description: "Nuxt uses native ES modules."
+navigation: false
 ---
 
 This guide helps explain what ES Modules are and how to make a Nuxt app (or upstream library) compatible with ESM.
@@ -31,7 +32,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?
@@ -161,7 +162,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 → 3.guide/1.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/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/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/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/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/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/modules/recipes-advanced#extend-typescript-config"}
+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 → 3.guide/1.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/5.best-practices → 3.guide/2.best-practices}/hydration.md

@@ -184,5 +184,5 @@ onMounted(() => {
 4. **Avoid side effects in setup**: Move browser-dependent code to `onMounted`
 
 ::tip
-You can read the [Vue documentation on SSR hydration mismatch](https://vuejs.org/guide/scaling-up/ssr.html#hydration-mismatch) for a better understanding of hydration.
+You can read the [Vue documentation on SSR hydration mismatch](https://vuejs.org/guide/scaling-up/ssr#hydration-mismatch) for a better understanding of hydration.
 ::

package/{2.guide/5.best-practices → 3.guide/2.best-practices}/performance.md

@@ -90,7 +90,7 @@ const show = ref(false)
 
 By using the Lazy prefix you can delay loading the component code until the right moment, which can be helpful for optimizing your JavaScript bundle size.
 
-:read-more{title="Lazy loading components" to="/docs/4.x/guide/directory-structure/app/components#dynamic-imports"}
+:read-more{title="Lazy loading components" to="/docs/4.x/directory-structure/app/components#dynamic-imports"}
 
 ### Lazy Hydration
 
@@ -106,7 +106,7 @@ It is not always necessary to hydrate (or make interactive) all the components o
 
 To optimize your app, you may want to delay the hydration of some components until they're visible, or until the browser is done with more important tasks.
 
-:read-more{title="Lazy hydration" to="/docs/4.x/guide/directory-structure/app/components#delayed-or-lazy-hydration"}
+:read-more{title="Lazy hydration" to="/docs/4.x/directory-structure/app/components#delayed-or-lazy-hydration"}
 
 ### Fetching data
 

package/3.guide/3.ai/.navigation.yml

@@ -0,0 +1,3 @@
+title: 'Working with AI'
+titleTemplate: 'Working with AI: %s'
+icon: i-lucide-bot