@nuxt/docs 3.20.1 → 3.21.0

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

@@ -6,7 +6,7 @@ navigation.icon: i-lucide-file-code-2
 
 Nuxt allows for select pages from your application to be rendered at build time. Nuxt will serve the prebuilt pages when requested instead of generating them on the fly.
 
-:read-more{title="Nuxt rendering modes" to="/docs/guide/concepts/rendering"}
+:read-more{title="Nuxt rendering modes" to="/docs/3.x/guide/concepts/rendering"}
 
 ## Crawl-based Pre-rendering
 
@@ -32,6 +32,10 @@ pnpm nuxt generate
 bun x nuxt generate
 ```
 
+```bash [deno]
+deno x nuxt generate
+```
+
 ::
 
 You can now deploy the `.output/public` directory to any static hosting service or preview it locally with `npx serve .output/public`.
@@ -45,7 +49,7 @@ Working of the Nitro crawler:
 
 This is important to understand since pages that are not linked to a discoverable page can't be pre-rendered automatically.
 
-::read-more{to="/docs/api/commands/generate#nuxt-generate"}
+::read-more{to="/docs/3.x/api/commands/generate#nuxt-generate"}
 Read more about the `nuxt generate` command.
 ::
 
@@ -54,6 +58,7 @@ Read more about the `nuxt generate` command.
 You can manually specify routes that [Nitro](/docs/3.x/guide/concepts/server-engine) will fetch and pre-render during the build or ignore routes that you don't want to pre-render like `/dynamic` in the `nuxt.config` file:
 
 ```ts twoslash [nuxt.config.ts]
+// @errors: 2353
 export default defineNuxtConfig({
   nitro: {
     prerender: {
@@ -67,6 +72,7 @@ export default defineNuxtConfig({
 You can combine this with the `crawlLinks` option to pre-render a set of routes that the crawler can't discover like your `/sitemap.xml` or `/robots.txt`:
 
 ```ts twoslash [nuxt.config.ts]
+// @errors: 2353
 export default defineNuxtConfig({
   nitro: {
     prerender: {
@@ -105,7 +111,7 @@ Read more about Nitro's `routeRules` configuration.
 
 As a shorthand, you can also configure this in a page file using [`defineRouteRules`](/docs/3.x/api/utils/define-route-rules).
 
-::read-more{to="/docs/guide/going-further/experimental-features#inlinerouterules" icon="i-lucide-star"}
+::read-more{to="/docs/3.x/guide/going-further/experimental-features#inlinerouterules" icon="i-lucide-star"}
 This feature is experimental and in order to use it you must enable the `experimental.inlineRouteRules` option in your `nuxt.config`.
 ::
 
@@ -154,7 +160,7 @@ prerenderRoutes('/api/content/article/my-article')
 </template>
 ```
 
-:read-more{title="prerenderRoutes" to="/docs/api/utils/prerender-routes"}
+:read-more{title="prerenderRoutes" to="/docs/3.x/api/utils/prerender-routes"}
 
 ### `prerender:routes` Nuxt hook
 

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

@@ -73,7 +73,7 @@ There are two ways to deploy a Nuxt application to any static hosting services:
 - Static site generation (SSG) with `ssr: true` pre-renders routes of your application at build time. (This is the default behavior when running `nuxt generate`.) It will also generate `/200.html` and `/404.html` single-page app fallback pages, which can render dynamic routes or 404 errors on the client (though you may need to configure this on your static host).
 - Alternatively, you can prerender your site with `ssr: false` (static single-page app). This will produce HTML pages with an empty `<div id="__nuxt"></div>` where your Vue app would normally be rendered. You will lose many SEO benefits of prerendering your site, so it is suggested instead to use [`<ClientOnly>`](/docs/3.x/api/components/client-only) to wrap the portions of your site that cannot be server rendered (if any).
 
-:read-more{title="Nuxt prerendering" to="/docs/getting-started/prerendering"}
+:read-more{title="Nuxt prerendering" to="/docs/3.x/getting-started/prerendering"}
 
 ### Client-side Only Rendering
 
@@ -95,9 +95,10 @@ Nuxt can be deployed to several cloud providers with a minimal amount of configu
 
 In addition to Node.js servers and static hosting services, a Nuxt project can be deployed with several well-tested presets and minimal amount of configuration.
 
-You can explicitly set the desired preset in the [`nuxt.config.ts`](/docs/3.x/guide/directory-structure/nuxt-config) file:
+You can explicitly set the desired preset in the [`nuxt.config.ts`](/docs/3.x/directory-structure/nuxt-config) file:
 
 ```ts twoslash [nuxt.config.ts]
+// @errors: 2353
 export default defineNuxtConfig({
   nitro: {
     preset: 'node-server',

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

@@ -5,7 +5,7 @@ navigation.icon: i-lucide-circle-check
 ---
 
 ::tip
-If you are a module author, you can find more specific information in the [Module Author's guide](/docs/3.x/guide/going-further/modules#testing).
+If you are a module author, you can find more specific information in the [Module Author's guide](/docs/3.x/guide/modules/testing).
 ::
 
 Nuxt offers first-class support for end-to-end and unit testing of your Nuxt application via `@nuxt/test-utils`, a library of test utilities and configuration that currently powers the [tests we use on Nuxt itself](https://github.com/nuxt/nuxt/tree/main/test) and tests throughout the module ecosystem.
@@ -63,7 +63,14 @@ We currently ship an environment for unit testing code that needs a [Nuxt](https
          {
            test: {
              name: 'unit',
-             include: ['test/{e2e,unit}/*.{test,spec}.ts'],
+             include: ['test/unit/*.{test,spec}.ts'],
+             environment: 'node',
+           },
+         },
+         {
+           test: {
+             name: 'e2e',
+             include: ['test/e2e/*.{test,spec}.ts'],
              environment: 'node',
            },
          },
@@ -265,9 +272,9 @@ it('can also mount an app', async () => {
 
 `renderSuspended` allows you to render any Vue component within the Nuxt environment using `@testing-library/vue`, allowing async setup and access to injections from your Nuxt plugins.
 
-This should be used together with utilities from Testing Library, e.g. `screen` and `fireEvent`. Install [@testing-library/vue](https://testing-library.com/docs/vue-testing-library/intro) in your project to use these.
+This should be used together with utilities from Testing Library, e.g. `screen` and `fireEvent`. Install [@testing-library/vue](https://testing-library.com/docs/vue-testing-library/intro/) in your project to use these.
 
-Additionally, Testing Library also relies on testing globals for cleanup. You should turn these on in your [Vitest config](https://vitest.dev/config/#globals).
+Additionally, Testing Library also relies on testing globals for cleanup. You should turn these on in your [Vitest config](https://vitest.dev/config/globals).
 
 The passed in component will be rendered inside a `<div id="test-wrapper"></div>`.
 
@@ -330,10 +337,10 @@ mockNuxtImport('useStorage', () => {
 ```
 
 ::note
-`mockNuxtImport` can only be used once per mocked import per test file. It is actually a macro that gets transformed to `vi.mock` and `vi.mock` is hoisted, as described [in the Vitest docs](https://vitest.dev/api/vi.html#vi-mock).
+`mockNuxtImport` can only be used once per mocked import per test file. It is actually a macro that gets transformed to `vi.mock` and `vi.mock` is hoisted, as described [in the Vitest docs](https://vitest.dev/api/vi#vi-mock).
 ::
 
-If you need to mock a Nuxt import and provide different implementations between tests, you can do it by creating and exposing your mocks using [`vi.hoisted`](https://vitest.dev/api/vi.html#vi-hoisted), and then use those mocks in `mockNuxtImport`. You then have access to the mocked imports, and can change the implementation between tests. Be careful to [restore mocks](https://vitest.dev/api/mock.html#mockrestore) before or after each test to undo mock state changes between runs.
+If you need to mock a Nuxt import and provide different implementations between tests, you can do it by creating and exposing your mocks using [`vi.hoisted`](https://vitest.dev/api/vi#vi-hoisted), and then use those mocks in `mockNuxtImport`. You then have access to the mocked imports, and can change the implementation between tests. Be careful to [restore mocks](https://vitest.dev/api/mock#mockrestore) before or after each test to undo mock state changes between runs.
 
 ```ts twoslash
 import { vi } from 'vitest'
@@ -624,7 +631,7 @@ Please use the options below for the `setup` method.
   - Type: `number | undefined`
   - Default: `undefined`
 
-- `host`: If provided, a URL to use as the test target instead of building and running a new server. Useful for running "real" end-to-end tests against a deployed version of your application, or against an already running local server (which may provide a significant reduction in test execution timings). See the [target host end-to-end example below](#target-host-end-to-end-example).
+- `host`: If provided, a URL to use as the test target instead of building and running a new server. Useful for running "real" end-to-end tests against a deployed version of your application, or against an already running local server (which may provide a significant reduction in test execution timings). See the [target host end-to-end example below](/docs/3.x/getting-started/testing#target-host-end-to-end-example).
   - Type: `string`
   - Default: `undefined`
 
@@ -647,7 +654,7 @@ For local development or automated deploy pipelines, testing against a separate
 
 To utilize a separate target host for end-to-end tests, simply provide the `host` property of the `setup` function with the desired URL.
 
-```ts twoslash
+```ts
 import { createPage, setup } from '@nuxt/test-utils/e2e'
 import { describe, expect, it } from 'vitest'
 
@@ -730,6 +737,9 @@ pnpm add -D @playwright/test @nuxt/test-utils
 ```bash [bun]
 bun add --dev @playwright/test @nuxt/test-utils
 ```
+```bash [deno]
+deno add --dev npm:@playwright/test npm:@nuxt/test-utils
+```
 ::
 
 You can provide global Nuxt configuration, with the same configuration details as the `setup()` function mentioned earlier in this section.

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

@@ -6,6 +6,35 @@ navigation.icon: i-lucide-circle-arrow-up
 
 ## Upgrading Nuxt
 
+### Latest Nuxt 3 release
+
+To upgrade Nuxt to the [latest v3 release](https://github.com/nuxt/nuxt/releases), use the `nuxt upgrade` command with `--channel=v3` flag.
+
+::code-group{sync="pm"}
+
+```bash [npm]
+npx nuxt upgrade --dedupe --channel=v3
+```
+
+```bash [yarn]
+yarn nuxt upgrade --dedupe --channel=v3
+```
+
+```bash [pnpm]
+pnpm nuxt upgrade --dedupe --channel=v3
+```
+
+```bash [bun]
+bun x nuxt upgrade --dedupe --channel=v3
+```
+
+::
+
+::note
+This will only work if you _already have_ a version of `@nuxt/cli` which has the `--channel` flag implemented. If this does not work, you can instead use `nuxi@latest` for the initial upgrade.
+E.g. `npx nuxi@latest upgrade --dedupe --channel=v3`
+::
+
 ### Latest release
 
 To upgrade Nuxt to the [latest release](https://github.com/nuxt/nuxt/releases), use the `nuxt upgrade` command.
@@ -28,6 +57,10 @@ pnpm nuxt upgrade
 bun x nuxt upgrade
 ```
 
+```bash [deno]
+deno x nuxt upgrade
+```
+
 ::
 
 ### Nightly Release Channel
@@ -99,46 +132,47 @@ For now, you need to define the compatibility version in each layer that opts in
 
 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.
 
-Breaking or significant changes will be noted here along with migration steps for backward/forward compatibility.
-
-::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
 
-To facilitate the upgrade process, we have collaborated with the [Codemod](https://github.com/codemod-com/codemod) team to automate many migration steps with some open-source codemods.
+To facilitate the upgrade process, we have collaborated with the [Codemod](https://github.com/codemod/codemod) team to automate many migration steps with some open-source codemods.
 
 ::note
 If you encounter any issues, please report them to the Codemod team with `npx codemod feedback` 🙏
 ::
 
-For a complete list of Nuxt 4 codemods, detailed information on each, their source, and various ways to run them, visit the [Codemod Registry](https://go.codemod.com/codemod-registry).
+For a complete list of Nuxt 4 codemods, detailed information on each, their source, and various ways to run them, visit the [Codemod Registry](https://app.codemod.com/registry).
 
 You can run all the codemods mentioned in this guide using the following `codemod` recipe:
 
 ::code-group
 
 ```bash [npm]
-# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+# Using pinned version due to https://github.com/codemod/codemod/issues/1710
 npx codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
 ```bash [yarn]
-# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+# Using pinned version due to https://github.com/codemod/codemod/issues/1710
 yarn dlx codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
 ```bash [pnpm]
-# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+# Using pinned version due to https://github.com/codemod/codemod/issues/1710
 pnpm dlx codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
 ```bash [bun]
-# Using pinned version due to https://github.com/codemod-com/codemod/issues/1710
+# Using pinned version due to https://github.com/codemod/codemod/issues/1710
 bun x codemod@0.18.7 nuxt/4/migration-recipe
 ```
 
+```bash [deno]
+# Using pinned version due to https://github.com/codemod/codemod/issues/1710
+deno x codemod@0.18.7 nuxt/4/migration-recipe
+```
+
 ::
 
 This command will execute all codemods in sequence, with the option to deselect any that you do not wish to run. Each codemod is also listed below alongside its respective change and can be executed independently.
@@ -153,11 +187,11 @@ Nuxt now defaults to a new directory structure, with backwards compatibility (so
 
 #### What Changed
 
-* the new Nuxt default `srcDir` is `app/` by default, and most things are resolved from there.
-* `serverDir` now defaults to `<rootDir>/server` rather than `<srcDir>/server`
-* `layers/`, `modules/` and `public/` are resolved relative to `<rootDir>` by default
-* if using [Nuxt Content v2.13+](https://github.com/nuxt/content/pull/2649), `content/` is resolved relative to `<rootDir>`
-* a new `dir.app` is added, which is the directory we look for `router.options.ts` and `spa-loading-template.html` - this defaults to `<srcDir>/`
+- the new Nuxt default `srcDir` is `app/` by default, and most things are resolved from there.
+- `serverDir` now defaults to `<rootDir>/server` rather than `<srcDir>/server`
+- `layers/`, `modules/` and `public/` are resolved relative to `<rootDir>` by default
+- if using [Nuxt Content v2.13+](https://github.com/nuxt/content/pull/2649), `content/` is resolved relative to `<rootDir>`
+- a new `dir.app` is added, which is the directory we look for `router.options.ts` and `spa-loading-template.html` - this defaults to `<srcDir>/`
 
 <details>
 
@@ -193,6 +227,10 @@ server/
 nuxt.config.ts
 ```
 
+::note
+With this new structure, the `~` alias now points to the `app/` directory by default (your `srcDir`). This means `~/components` resolves to `components/`, `~/pages` to `pages/`, etc.
+::
+
 </details>
 
 👉 For more details, see the [PR implementing this change](https://github.com/nuxt/nuxt/pull/27029).
@@ -318,15 +356,15 @@ Now modules are loaded in the correct order:
 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
+- 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
+- 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
 
@@ -358,7 +396,7 @@ export default defineNuxtConfig({
 // 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/3.x/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.
+If you encounter issues with module order dependencies due to needing to register a hook, consider using the [`modules:done` hook](/docs/3.x/guide/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.
 
@@ -433,9 +471,9 @@ export default defineNuxtConfig({
 [Unhead](https://unhead.unjs.io/), used to generate `<head>` tags, has been updated to version 2. While mostly compatible it includes several breaking changes
 for lower-level APIs.
 
-* Removed props: `vmid`, `hid`, `children`, `body`.
-* Promise input no longer supported.
-* Tags are now sorted using Capo.js by default.
+- Removed props: `vmid`, `hid`, `children`, `body`.
+- Promise input no longer supported.
+- Tags are now sorted using Capo.js by default.
 
 #### Migration Steps
 
@@ -443,7 +481,7 @@ The above changes should have minimal impact on your app.
 
 If you have issues you should verify:
 
-* You're not using any of the removed props.
+- You're not using any of the removed props.
 
 ```diff
 useHead({
@@ -456,7 +494,7 @@ useHead({
 })
 ```
 
-* If you're using [Template Params](https://unhead.unjs.io/docs/head/guides/plugins/template-params) or [Alias Tag Sorting](https://unhead.unjs.io/docs/head/guides/plugins/alias-sorting), you will need to explicitly opt in to these features now.
+- If you're using [Template Params](https://unhead.unjs.io/docs/head/guides/plugins/template-params) or [Alias Tag Sorting](https://unhead.unjs.io/docs/head/guides/plugins/alias-sorting), you will need to explicitly opt in to these features now.
 
 ```ts
 import { AliasSortingPlugin, TemplateParamsPlugin } from '@unhead/vue/plugins'
@@ -493,7 +531,7 @@ export default defineNuxtConfig({
 
 #### What Changed
 
-When rendering a client-only page (with `ssr: false`), we optionally render a loading screen (from `app/spa-loading-template.html`), within the Nuxt app root:
+When rendering a client-only page (with `ssr: false`), we optionally render a loading screen (from `~/app/spa-loading-template.html` - note that this has also changed to `~/spa-loading-template.html` in Nuxt 4), within the Nuxt app root:
 
 ```html
 <div id="__nuxt">
@@ -638,7 +676,7 @@ For example, if your site requires a `useFetch` call for every page (for example
 
 Make sure that any unique key of your data is always resolvable to the same data. For example, if you are using `useAsyncData` to fetch data related to a particular page, you should provide a key that uniquely matches that data. (`useFetch` should do this automatically for you.)
 
-```ts [app/pages/test/[slug\\].vue]
+```ts [pages/test/[slug\\].vue]
 // 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()
@@ -989,15 +1027,15 @@ In Nuxt v3 we moved to a 'virtual' syntax with a `getContents()` function which
 
 In addition, `lodash/template` has had a succession of security issues. These do not really apply to Nuxt projects because it is being used at build-time, not runtime, and by trusted code. However, they still appear in security audits. Moreover, `lodash` is a hefty dependency and is unused by most projects.
 
-Finally, providing code serialization functions directly within Nuxt is not ideal. Instead, we maintain projects like [unjs/knitwork](http://github.com/unjs/knitwork) which can be dependencies of your project, and where security issues can be reported/resolved directly without requiring an upgrade of Nuxt itself.
+Finally, providing code serialization functions directly within Nuxt is not ideal. Instead, we maintain projects like [unjs/knitwork](https://github.com/unjs/knitwork) which can be dependencies of your project, and where security issues can be reported/resolved directly without requiring an upgrade of Nuxt itself.
 
 #### Migration Steps
 
 We have raised PRs to update modules using EJS syntax, but if you need to do this yourself, you have three backwards/forwards-compatible alternatives:
 
-* Moving your string interpolation logic directly into `getContents()`.
-* Using a custom function to handle the replacement, such as in https://github.com/nuxt-modules/color-mode/pull/240.
-* Use `es-toolkit/compat` (a drop-in replacement for lodash template), as a dependency of _your_ project rather than Nuxt:
+- Moving your string interpolation logic directly into `getContents()`.
+- Using a custom function to handle the replacement, such as in https://github.com/nuxt-modules/color-mode/pull/240.
+- Use `es-toolkit/compat` (a drop-in replacement for lodash template), as a dependency of _your_ project rather than Nuxt:
 
 ```diff
 + import { readFileSync } from 'node:fs'
@@ -1080,11 +1118,11 @@ There are two approaches:
 Nuxt now generates separate TypeScript configurations for different contexts to provide better type-checking experiences:
 
 1. **New TypeScript configuration files**: Nuxt now generates additional TypeScript configurations:
-   * `.nuxt/tsconfig.app.json` - For your app code (Vue components, composables, etc.)
-   * `.nuxt/tsconfig.server.json` - For your server-side code (Nitro/server directory)  
-   * `.nuxt/tsconfig.node.json` - For your build-time code (modules, `nuxt.config.ts`, etc.)
-   * `.nuxt/tsconfig.shared.json` - For code shared between app and server contexts (like types and non-environment specific utilities)
-   * `.nuxt/tsconfig.json` - Legacy configuration for backward compatibility
+   - `.nuxt/tsconfig.app.json` - For your app code (Vue components, composables, etc.)
+   - `.nuxt/tsconfig.server.json` - For your server-side code (Nitro/server directory)  
+   - `.nuxt/tsconfig.node.json` - For your build-time code (modules, `nuxt.config.ts`, etc.)
+   - `.nuxt/tsconfig.shared.json` - For code shared between app and server contexts (like types and non-environment specific utilities)
+   - `.nuxt/tsconfig.json` - Legacy configuration for backward compatibility
 
 2. **Backward compatibility**: Existing projects that extend `.nuxt/tsconfig.json` will continue to work as before.
 
@@ -1113,8 +1151,13 @@ However, to take advantage of improved type checking, you can opt in to the new
 
 1. **Update your root `tsconfig.json`** to use project references:
 
+   ::note
+   If your `tsconfig.json` currently has an `"extends": "./.nuxt/tsconfig.json"` line, **remove it** before adding the references. Project references and extends are mutually exclusive.
+   ::
+
    ```json
    {
+     // Remove "extends": "./.nuxt/tsconfig.json" if present
      "files": [],
      "references": [
        { "path": "./.nuxt/tsconfig.app.json" },
@@ -1135,30 +1178,38 @@ However, to take advantage of improved type checking, you can opt in to the new
    ```
 
 4. **Move all type augmentations into their appropriate context**:
-   * If you are augmenting types for the app context, move the files to the `app/` directory.
-   * If you are augmenting types for the server context, move the files to the `server/` directory.
-   * If you are augmenting types that are **shared between the app and server**, move the files to the `shared/` directory.
+   - If you are augmenting types for the app context, move the files to the `app/` directory.
+   - If you are augmenting types for the server context, move the files to the `server/` directory.
+   - If you are augmenting types that are **shared between the app and server**, move the files to the `shared/` directory.
 
     ::warning
     Augmenting types from outside the `app/`, `server/`, or `shared/` directories will not work with the new project references setup.
     ::
 
-5. **Configure Node.js TypeScript options** if needed:
+5. **Configure TypeScript options** if needed:
    <!-- @case-police-ignore tsConfig -->
 
    ```ts
    export default defineNuxtConfig({
      typescript: {
-       // Customize app/server TypeScript config
+       // customize tsconfig.app.json
        tsConfig: {
-         compilerOptions: {
-           strict: true,
-         },
+         // ...
        },
-       // Customize build-time TypeScript config
+       // customize tsconfig.shared.json
+       sharedTsConfig: {
+         // ...
+       },
+       // customize tsconfig.node.json
        nodeTsConfig: {
-         compilerOptions: {
-           strict: true,
+         // ...
+       },
+     },
+     nitro: {
+       typescript: {
+         // customize tsconfig.server.json
+         tsConfig: {
+           // ...
          },
        },
      },
@@ -1177,11 +1228,11 @@ The new configuration provides better type safety and IntelliSense for projects
 
 Four experimental features are no longer configurable in Nuxt 4:
 
-* `experimental.treeshakeClientOnly` will be `true` (default since v3.0)
-* `experimental.configSchema` will be `true` (default since v3.3)
-* `experimental.polyfillVueUseHead` will be `false` (default since v3.4)
-* `experimental.respectNoSSRHeader` will be `false` (default since v3.4)
-* `vite.devBundler` is no longer configurable - it will use `vite-node` by default
+- `experimental.treeshakeClientOnly` will be `true` (default since v3.0)
+- `experimental.configSchema` will be `true` (default since v3.3)
+- `experimental.polyfillVueUseHead` will be `false` (default since v3.4)
+- `experimental.respectNoSSRHeader` will be `false` (default since v3.4)
+- `vite.devBundler` is no longer configurable - it will use `vite-node` by default
 
 #### Reasons for Change
 
@@ -1189,9 +1240,9 @@ These options have been set to their current values for some time and we do not
 
 #### Migration Steps
 
-* `polyfillVueUseHead` is implementable in user-land with [this plugin](https://github.com/nuxt/nuxt/blob/f209158352b09d1986aa320e29ff36353b91c358/packages/nuxt/src/head/runtime/plugins/vueuse-head-polyfill.ts#L10-L11)
+- `polyfillVueUseHead` is implementable in user-land with [this plugin](https://github.com/nuxt/nuxt/blob/f209158352b09d1986aa320e29ff36353b91c358/packages/nuxt/src/head/runtime/plugins/vueuse-head-polyfill.ts#L10-L11)
 
-* `respectNoSSRHeader`is implementable in user-land with [server middleware](https://github.com/nuxt/nuxt/blob/c660b39447f0d5b8790c0826092638d321cd6821/packages/nuxt/src/core/runtime/nitro/no-ssr.ts#L8-L9)
+- `respectNoSSRHeader`is implementable in user-land with [server middleware](https://github.com/nuxt/nuxt/blob/c660b39447f0d5b8790c0826092638d321cd6821/packages/nuxt/src/core/runtime/nitro/no-ssr.ts#L8-L9)
 
 ### Removal of Top-Level `generate` Configuration
 
@@ -1201,8 +1252,8 @@ These options have been set to their current values for some time and we do not
 
 The top-level `generate` configuration option is no longer available in Nuxt 4. This includes all of its properties:
 
-* `generate.exclude` - for excluding routes from prerendering
-* `generate.routes` - for specifying routes to prerender
+- `generate.exclude` - for excluding routes from prerendering
+- `generate.routes` - for specifying routes to prerender
 
 #### Reasons for Change
 
@@ -1257,7 +1308,7 @@ Static sites             | ✅             | ✅                | ✅
 
 The migration guide provides a step-by-step comparison of Nuxt 2 features to Nuxt 3+ features and guidance to adapt your current application.
 
-::read-more{to="/docs/migration/overview"}
+::read-more{to="/docs/3.x/migration/overview"}
 Check out the **guide to migrating from Nuxt 2 to Nuxt 3**.
 ::
 
@@ -1265,6 +1316,6 @@ Check out the **guide to migrating from Nuxt 2 to Nuxt 3**.
 
 If you prefer to progressively migrate your Nuxt 2 application to Nuxt 3, you can use Nuxt Bridge. Nuxt Bridge is a compatibility layer that allows you to use Nuxt 3+ features in Nuxt 2 with an opt-in mechanism.
 
-::read-more{to="/docs/bridge/overview"}
+::read-more{to="/docs/3.x/bridge/overview"}
 **Migrate from Nuxt 2 to Nuxt Bridge**
 ::

package/{2.guide/1.directory-structure → 2.directory-structure}/0.nuxt.md

@@ -6,7 +6,7 @@ navigation.icon: i-vscode-icons-folder-type-temp
 ---
 
 ::important
-This directory should be added to your [`.gitignore`](/docs/3.x/guide/directory-structure/gitignore) file to avoid pushing the dev build output to your repository.
+This directory should be added to your [`.gitignore`](/docs/3.x/directory-structure/gitignore) file to avoid pushing the dev build output to your repository.
 ::
 
 This directory is interesting if you want to learn more about the files Nuxt generates based on your directory structure.

package/{2.guide/1.directory-structure → 2.directory-structure}/0.output.md

@@ -6,12 +6,12 @@ navigation.icon: i-vscode-icons-folder-type-package
 ---
 
 ::important
-This directory should be added to your [`.gitignore`](/docs/3.x/guide/directory-structure/gitignore) file to avoid pushing the build output to your repository.
+This directory should be added to your [`.gitignore`](/docs/3.x/directory-structure/gitignore) file to avoid pushing the build output to your repository.
 ::
 
 Use this directory to deploy your Nuxt application to production.
 
-:read-more{to="/docs/getting-started/deployment"}
+:read-more{to="/docs/3.x/getting-started/deployment"}
 
 ::warning
 You should not touch any files inside since the whole directory will be re-created when running [`nuxt build`](/docs/3.x/api/commands/build).

package/{2.guide/1.directory-structure → 2.directory-structure}/1.assets.md

@@ -9,8 +9,8 @@ The directory usually contains the following types of files:
 
 - Stylesheets (CSS, SASS, etc.)
 - Fonts
-- Images that won't be served from the [`public/`](/docs/3.x/guide/directory-structure/public) directory.
+- Images that won't be served from the [`public/`](/docs/3.x/directory-structure/public) directory.
 
-If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/3.x/guide/directory-structure/public) directory.
+If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/3.x/directory-structure/public) directory.
 
-:read-more{to="/docs/getting-started/assets"}
+:read-more{to="/docs/3.x/getting-started/assets"}