@nuxt/docs-nightly 4.5.1-29752449.30d24817 → 4.5.2-2610052030-052d82e

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

@@ -36,17 +36,11 @@ deno x nuxt upgrade
 
 ### Nightly Release Channel
 
-To use the latest Nuxt build and test features before their release, read about the [nightly release channel](/docs/4.x/guide/going-further/nightly-release-channel) guide.
+To use the latest Nuxt build and test features before their release, read about the [nightly release channel](/docs/guide/going-further/nightly-release-channel) guide.
 
 ## Testing Nuxt 5
 
-Nuxt 5 is **currently in development**. Until the release, it is possible to test many of Nuxt 5's breaking changes from Nuxt version 4.2+.
-
-### Opting in to Nuxt 5
-
-First, upgrade Nuxt to the [latest release](https://github.com/nuxt/nuxt/releases).
-
-Then you can set your `future.compatibilityVersion` to match Nuxt 5 behavior:
+Nuxt 5 is **currently in development**. From Nuxt 4.2+ you can test many of its breaking changes by setting `future.compatibilityVersion` to `5`:
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
@@ -56,287 +50,93 @@ export default defineNuxtConfig({
 })
 ```
 
-When you set your `future.compatibilityVersion` to `5`, defaults throughout your Nuxt configuration will change to opt in to Nuxt v5 behavior, including:
-
-- **Vite Environment API**: Automatically enables the new [Vite Environment API](/docs/4.x/getting-started/upgrade#migration-to-vite-environment-api) for improved build configuration
-- **Normalized Page Names**: Page component names will [match their route names](/docs/4.x/getting-started/upgrade#normalized-page-component-names) for consistent `<KeepAlive>` behavior
-- **`clearNuxtState` resets to defaults**: `clearNuxtState` will [reset state to its initial value](/docs/4.x/getting-started/upgrade#respect-defaults-when-clearing-usestate) instead of setting it to `undefined`
-- **Non-async `callHook`**: [`callHook` may return `void`](/docs/4.x/getting-started/upgrade#non-async-callhook) instead of always returning a `Promise`
-- **Comment node placeholders**: Client-only components use [comment nodes instead of `<div>`](/docs/4.x/getting-started/upgrade#client-only-comment-placeholders) as SSR placeholders, fixing a scoped styles hydration issue
-- **Stricter side-effect imports**: The generated `tsconfig.json` enables [`noUncheckedSideEffectImports`](/docs/4.x/getting-started/upgrade#stricter-side-effect-imports) to match the TypeScript 7 default
-- **Vue Options API disabled**: The [Options API is compiled out of the client bundle](/docs/4.x/getting-started/upgrade#vue-options-api-disabled-by-default) to reduce its size
-- Other Nuxt 5 improvements and changes as they become available
+Defaults throughout your Nuxt configuration then change to opt in to Nuxt 5 behaviour. On Nuxt 4 this covers:
+
+- **Vite Environment API**: [`experimental.viteEnvironmentApi`](/docs/guide/going-further/experimental-features#viteenvironmentapi) is enabled, changing how Vite plugins are registered and configured
+- **Case-sensitive routing**: page routes match URL casing exactly, consistent with Nitro, so `/About` no longer matches `pages/about.vue`
+- **Normalized page names**: page component names [match their route names](/docs/guide/going-further/experimental-features#normalizepagenames) for consistent `<KeepAlive>` behaviour
+- **Serializable page meta**: [`experimental.extractSerializablePageMeta`](/docs/guide/going-further/experimental-features#extractserializablepagemeta) extracts statically analysable `definePageMeta` values at build time
+- **Client-side payload extraction**: [`experimental.payloadExtraction`](/docs/guide/going-further/experimental-features#payloadextraction) becomes `'client'`, inlining the payload in the HTML of a prerendered page
+- **`clearNuxtState` resets to defaults**: `clearNuxtState` resets state to the initial value of [`useState`](/docs/api/composables/use-state) instead of setting it to `undefined`
+- **Non-async `callHook`**: `callHook` may return `void` instead of always returning a `Promise`
+- **Early return from `navigateTo`**: [`experimental.navigateToEarlyReturn`](/docs/guide/going-further/experimental-features#navigatetoearlyreturn) stops a middleware continuing after it redirects
+- **Server-only head composables**: `useServerHead`, `useServerHeadSafe` and `useServerSeoMeta` are no longer auto-imported, `unhead.legacy` is ignored, Unhead's legacy plugins are no longer registered and Capo sorting is always on
+- **PostCSS defaults off**: `autoprefixer` and `cssnano` are no longer configured unless you enable them in `postcss.plugins`
+- **Keyed composables require `source`**: a [`optimization.keyedComposables`](/docs/api/nuxt-config#keyedcomposables) entry without a string `source` is no longer matched through its auto-import
+- **Comment node placeholders**: client-only components use [comment nodes instead of `<div>`](/docs/guide/going-further/experimental-features#clientnodeplaceholder) as SSR placeholders
+- **Typed pages**: [`experimental.typedPages`](/docs/guide/going-further/experimental-features#typedpages) is enabled for type-checked routing
+- **Error response format**: `experimental.inlineErrorRendering` is enabled, so page errors return the error page and server route errors return JSON, [regardless of the request headers](https://nuxt.com/docs/5.x/getting-started/upgrade#error-format-depends-on-where-the-error-is-thrown)
+- **Typed `$fetch`**: [`experimental.routeTypedFetch`](/docs/guide/going-further/experimental-features#routetypedfetch) types `$fetch` and `useFetch` from the generated route types
+- **Nitro auto-imports off**: server code imports Nitro's helpers explicitly rather than relying on the auto-import compatibility layer
+- **Vue Options API disabled**: the Options API is compiled out of the client bundle to reduce its size
+- **Stricter side-effect imports**: the generated `tsconfig.json` enables `noUncheckedSideEffectImports`
+- **TypeScript `baseUrl` ignored**: generated TypeScript configurations no longer use `compilerOptions.baseUrl` to resolve Nuxt aliases
 
 ::note
-This section is subject to change until the final release, so please check back here regularly if you are testing Nuxt 5 using `future.compatibilityVersion: 5`.
+This list describes what the flag changes on Nuxt 4. Nuxt 5 itself carries further changes that no flag enables here, such as the upgrade to Nitro v3.
 ::
 
-Breaking or significant changes will be noted below along with migration steps for backward/forward compatibility.
-
-### Migration to Vite Environment API
+The migration steps for each change, and everything else the upgrade brings, are documented in the [Nuxt 5 upgrade guide](https://nuxt.com/docs/5.x/getting-started/upgrade).
 
-🚦 **Impact Level**: Medium
-
-#### What Changed
+## Moving to `nuxt/server`
 
-Nuxt 5 migrates to Vite 6's new [Environment API](https://vite.dev/guide/api-environment), which formalizes the concept of environments and provides better control over configuration per environment.
+From Nuxt 4.6, server code can import its handler and helpers from [`nuxt/server`](/docs/guide/going-further/server-imports) rather than from h3, so the same file runs on Nuxt 4 (`nitropack` v2 and h3 v1) and on [Nuxt 5](https://nuxt.com/docs/5.x/getting-started/upgrade) (Nitro v3 and h3 v2).
 
-Previously, Nuxt used separate client and server Vite configurations. Now, Nuxt uses a shared Vite configuration with environment-specific plugins that use the `applyToEnvironment()` method to target specific environments.
+On Nuxt 4.6, import `defineEventHandler` and the helpers from `nuxt/server` explicitly. The auto-imported names of the same spelling are h3 v1's, and h3's `defineEventHandler` passes your handler a different event from the one the `nuxt/server` helpers read.
 
-::tip
-You can test this feature early by setting `future.compatibilityVersion: 5` (see [Testing Nuxt 5](/docs/4.x/getting-started/upgrade#testing-nuxt-5)) or by enabling it explicitly with `experimental.viteEnvironmentApi: true`.
-::
-
-**Key changes:**
-
-1. **Deprecated environment-specific `extendViteConfig()`**: The `server` and `client` options in `extendViteConfig()` are deprecated and will show warnings when used.
-
-2. **Changed plugin registration**: Vite plugins registered with `addVitePlugin()` and only targeting one environment (by passing `server: false` or `client: false`) will not have their `config` or `configResolved` hooks called.
-
-3. **Shared configuration**: The `vite:extendConfig` and `vite:configResolved` hooks now work with a shared configuration rather than separate client/server configs.
-
-#### Reasons for Change
-
-The Vite Environment API provides:
-- Better consistency between development and production builds
-- More granular control over environment-specific configuration
-- Improved performance and plugin architecture
-- Support for custom environments beyond just client and server
-
-#### Migration Steps
-
-##### 1. Migrate to use Vite plugins
-
-We would recommend you use a Vite plugin instead of `extendViteConfig`, `vite:configResolved` and `vite:extendConfig`.
-
-```ts
-// Before
-extendViteConfig((config) => {
-  config.optimizeDeps.include.push('my-package')
-}, { server: false })
-
-nuxt.hook('vite:extendConfig' /* or vite:configResolved */, (config, { isClient }) => {
-  if (isClient) {
-    config.optimizeDeps.include.push('my-package')
-  }
-})
-
-// After
-addVitePlugin(() => ({
-  name: 'my-plugin',
-  config (config) {
-    // you can set global vite configuration here
-  },
-  configResolved (config) {
-    // you can access the fully resolved vite configuration here
-  },
-  configEnvironment (name, config) {
-    // you can set environment-specific vite configuration here
-    if (name === 'client') {
-      config.optimizeDeps ||= {}
-      config.optimizeDeps.include ||= []
-      config.optimizeDeps.include.push('my-package')
-    }
-  },
-  applyToEnvironment (environment) {
-    return environment.name === 'client'
-  },
-}))
+```diff [server/api/hello.ts]
++ import { defineEventHandler, getQuery } from 'nuxt/server'
++
+ export default defineEventHandler((event) => {
+   const { name } = getQuery<{ name?: string }>(event)
+   return { message: `Hello, ${name ?? 'world'}!` }
+ })
 ```
 
-##### 2. Migrate Vite plugins to use environments
-
-Instead of using `addVitePlugin` with `server: false` or `client: false`, you can instead use the new `applyToEnvironment` hook within your plugin.
-
-```ts
-// Before
-addVitePlugin(() => ({
-  name: 'my-plugin',
-  config (config) {
-    config.optimizeDeps.include.push('my-package')
-  },
-}), { client: false })
-
-// After
-addVitePlugin(() => ({
-  name: 'my-plugin',
-  config (config) {
-    // you can set global vite configuration here
-  },
-  configResolved (config) {
-    // you can access the fully resolved vite configuration here
-  },
-  configEnvironment (name, config) {
-    // you can set environment-specific vite configuration here
-    if (name === 'client') {
-      config.optimizeDeps ||= {}
-      config.optimizeDeps.include ||= []
-      config.optimizeDeps.include.push('my-package')
-    }
-  },
-  applyToEnvironment (environment) {
-    return environment.name === 'client'
-  },
-}))
-```
-
-::read-more{to="https://vite.dev/guide/api-environment" target="_blank"}
-Learn more about Vite's Environment API
-::
-
-### Non-Async `callHook`
-
-🚦 **Impact Level**: Minimal
-
-#### What Changed
-
-With the upgrade to [hookable v6](https://github.com/unjs/hookable), `callHook` may now return `void` instead of always returning `Promise<void>`. This is a significant performance improvement that avoids unnecessary `Promise` allocations when there are no registered hooks or all hooks are synchronous.
-
-By default (with `compatibilityVersion: 4`), Nuxt wraps `callHook` with `Promise.resolve()` so that existing `.then()` and `.catch()` chaining continues to work. With `compatibilityVersion: 5`, this wrapper is removed.
-
-::tip
-This affects both build-time Nuxt hooks (used by Nuxt modules) and runtime Nuxt hooks (which you might use in your application code).
-::
-
-#### Reasons for Change
-
-Hookable v6's `callHook` is 20-40x faster because it avoids creating a `Promise` when one is not needed. This benefits applications with many hook call sites.
-
-#### Migration Steps
-
-If you or your modules use `callHook` with `.then()` or `.catch()` chaining, switch to `await`:
-
-```diff
-- nuxtApp.callHook('my:hook', data).then(() => { ... })
-+ await nuxtApp.callHook('my:hook', data)
-```
-
-```diff
-- nuxtApp.hooks.callHook('my:hook', data).catch(err => { ... })
-+ try { await nuxtApp.hooks.callHook('my:hook', data) } catch (err) { ... }
-```
-
-::tip
-You can test this feature early by setting `future.compatibilityVersion: 5` (see [Testing Nuxt 5](/docs/4.x/getting-started/upgrade#testing-nuxt-5)) or by enabling it explicitly with `experimental.asyncCallHook: false`.
-::
-
-Alternatively, you can ensure `callHook` always returns a `Promise` with:
-
-```ts twoslash [nuxt.config.ts]
-export default defineNuxtConfig({
-  experimental: {
-    asyncCallHook: true,
-  },
-})
-```
-
-### Client-Only Comment Placeholders
-
-🚦 **Impact Level**: Minimal
-
-#### What Changed
-
-With `compatibilityVersion: 5`, client-only components (`.client.vue` files and `createClientOnly()` wrappers) now render an HTML comment (`<!--placeholder-->`) on the server instead of an empty `<div>` element.
-
-#### Reasons for Change
-
-When the placeholder `<div>` and the actual component root share the same tag name, Vue's runtime skips re-applying `setScopeId` during hydration. This causes scoped styles to be missing after the component mounts. Using a comment node avoids the tag name collision entirely.
-
-#### Migration Steps
-
-If you rely on the placeholder `<div>` to inherit attributes (`class`, `style`, etc.) for layout purposes (e.g., reserving space to prevent layout shift), wrap the component in `<ClientOnly>` with a `#fallback` slot instead:
-
-```diff
-- <MyComponent class="placeholder" style="min-height: 200px" />
-+ <ClientOnly>
-+   <MyComponent />
-+   <template #fallback>
-+     <div class="placeholder" style="min-height: 200px"></div>
-+   </template>
-+ </ClientOnly>
-```
-
-::tip
-You can test this feature early by setting `future.compatibilityVersion: 5` (see [Testing Nuxt 5](/docs/4.x/getting-started/upgrade#testing-nuxt-5)) or by enabling it explicitly with `experimental.clientNodePlaceholder: true`.
-::
-
-Alternatively, you can revert to the previous `<div>` placeholder behavior with:
-
-```ts twoslash [nuxt.config.ts]
-export default defineNuxtConfig({
-  experimental: {
-    clientNodePlaceholder: false,
-  },
-})
-```
-
-### Stricter Side-Effect Imports
-
-🚦 **Impact Level**: Minimal
-
-#### What Changed
-
-With `compatibilityVersion: 5`, Nuxt's generated `tsconfig.json` enables [`noUncheckedSideEffectImports`](https://www.typescriptlang.org/tsconfig/#noUncheckedSideEffectImports). This is a default in TypeScript 7, so adopting it early keeps your project aligned ahead of that upgrade.
-
-With this option on, a side-effect-only import (`import './setup'`) that TypeScript cannot resolve to a module is now a type error, whereas it was previously ignored. This only affects type-checking (`nuxt typecheck` and your editor), not runtime behavior.
-
-#### Reasons for Change
-
-Unresolved side-effect imports were silently ignored, so a typo or a deleted file could pass type-checking. Flagging them catches these mistakes and matches the TypeScript 7 default.
-
-#### Migration Steps
-
-If type-checking now errors on a side-effect import of a non-code asset (for example `import '~/assets/styles.css'`), add an ambient module declaration so TypeScript knows the import is valid:
-
-```ts [types.d.ts]
-declare module '*.css' {}
-```
-
-::tip
-You can revert to the previous behavior by disabling the option in your `nuxt.config`:
-
-<!-- @case-police-ignore tsConfig -->
-
-```ts twoslash [nuxt.config.ts]
-export default defineNuxtConfig({
-  typescript: {
-    tsConfig: {
-      compilerOptions: {
-        noUncheckedSideEffectImports: false,
-      },
-    },
-  },
+On Nuxt 5 the same names are auto-imported from `nuxt/server`, so explicit imports written on Nuxt 4.6 keep working unchanged.
+
+### Differences From h3 v1
+
+| h3 v1 | `nuxt/server` |
+|---|---|
+| `sendRedirect(event, location)` sends the response. | `sendRedirect(event, location)` returns the response body: `return sendRedirect(event, '/login')`. |
+| `getRouterParam(event, name)` and `getRouterParams(event)` return decoded values. | They return the values as they appear in the URL. Pass `{ decode: true }` to decode them. |
+| `handleCors(event, options)` returns `true` when it answered a preflight request. | `handleCors(event, options)` returns the preflight `Response` to return from the handler, or `false`: `const preflight = handleCors(event, options); if (preflight) return preflight`. |
+| `handleCors` accepts a single origin string at runtime. | `origin` is `'*'`, `'null'`, an array of origins or patterns, or a function: wrap a single origin in an array. `maxAge` is a string of seconds, such as `'86400'`, or `false`. Import the `CorsOptions` type from `nuxt/server`. |
+| `readValidatedBody` and `getValidatedQuery` take a validation function. | They take a [Standard Schema](https://standardschema.dev) or a function. |
+| `createError({ statusCode, statusMessage })` | `createError({ status, statusText })` |
+| `isError(error)` | `isNuxtError(error)` |
+| h3's `useSession`, `getSession`, `updateSession` and `clearSession` seal an `h3` cookie with the `password` you pass. | They seal a `nuxt-session` cookie, by default with a secret derived from `appSecret`. The two are not interchangeable: a session one issues does not unseal with the other. |
+| `useRuntimeConfig(event)` | `useRuntimeConfig()`. There is no per-request form. |
+| Global `$fetch` | Not part of `nuxt/server`. Call a route of the app with `serverFetch(event, path)`, which returns a `Response`. For other URLs, plain `fetch` does not throw on a non-2xx status and does not parse JSON: check `response.ok` and call `response.json()`. |
+| `event.path` | `getRequestURL(event).pathname`, or `event.url.pathname`. |
+| `event.node` | Not part of `nuxt/server`. Use `event.req` and `event.res`. |
+| `getResponseHeader`, `setResponseHeader`, `appendResponseHeader`, `removeResponseHeader` | `event.res.headers.get()`, `.set()`, `.append()`, `.delete()` |
+| `getMethod(event)`, `isMethod(event, method)`, `assertMethod(event, method)` | Compare `event.req.method`. |
+| `readMultipartFormData(event)` | `await event.req.formData()` |
+| `readRawBody(event)`, `getRequestWebStream(event)` | `await event.req.arrayBuffer()` (or `.text()`), `event.req.body` |
+| `sanitizeStatusCode` | Not provided. |
+
+### Helpers Outside `nuxt/server`
+
+For a handler that needs h3 or Nitro helpers that `nuxt/server` does not provide, such as `readMultipartFormData`, `proxyRequest`, `useStorage` or `defineCachedEventHandler`, keep importing `defineEventHandler` and those helpers from `h3` (or `nitropack/runtime`) for that handler. Code that does this is tied to the server runtime and needs revisiting on Nuxt 5.
+
+```ts [server/api/upload.post.ts]
+import { defineEventHandler, readMultipartFormData } from 'h3'
+
+export default defineEventHandler(async (event) => {
+  const parts = await readMultipartFormData(event)
+  return { received: parts?.length ?? 0 }
 })
 ```
-::
-
-### Vue Options API Disabled by Default
-
-🚦 **Impact Level**: Minimal
-
-#### What Changed
-
-With `compatibilityVersion: 5`, Nuxt sets Vue's [`__VUE_OPTIONS_API__`](https://vuejs.org/api/compile-time-flags#VUE_OPTIONS_API) feature flag to `false`, which compiles Vue's Options API runtime out of the client bundle.
-
-#### Reasons for Change
 
-The Options API runtime ships in every client bundle even though most Nuxt applications are written with the Composition API and `<script setup>`. Dropping it shrinks the client bundle (around 6 kB minified / 2 kB gzipped on a minimal app).
+### `NUXT_E8012`
 
-#### Migration Steps
+A request fails with a `500` whose message starts with `[NUXT_E8012]` when a `nuxt/server` helper such as `readValidatedBody`, `getValidatedQuery`, `handleCors` or `useSession` receives an h3 event. This means the handler was defined with h3's `defineEventHandler` (usually the auto-imported one). Import `defineEventHandler` from `nuxt/server` in the same file as the helpers.
 
-If any of your components (or a dependency's components) use the Options API (`export default { data() {}, methods: {}, ... }`), re-enable it in your `nuxt.config`:
+### Application Secret
 
-```ts twoslash [nuxt.config.ts]
-export default defineNuxtConfig({
-  vue: {
-    optionsApi: true,
-  },
-})
-```
-
-::note
-`defineNuxtComponent` is unaffected: its `asyncData` and `head` options are handled through `setup()` rather than the Vue Options API, so it works regardless of this flag.
-::
+The `nuxt/server` session helpers and `deriveSecret` read `runtimeConfig.appSecret`, which you set with `NUXT_APP_SECRET`. On Nuxt 4, `nitropack` v2 parses environment overrides, so a secret made only of digits arrives as a number; see [the application secret](/docs/guide/going-further/runtime-config#application-secret) for how to avoid this.
 
 ## Migrating to Nuxt 4
 
@@ -432,7 +232,7 @@ Nuxt now defaults to a new directory structure, with backwards compatibility (so
 - `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>/`
-- a new [`shared/`](/docs/4.x/directory-structure/shared) directory is available for code shared between the Vue app and the Nitro server, with auto-imports for `shared/utils/` and `shared/types/`
+- a new [`shared/`](/docs/directory-structure/shared) directory is available for code shared between the Vue app and the Nitro server, with auto-imports for `shared/utils/` and `shared/types/`
 
 <details>
 
@@ -591,7 +391,7 @@ export default defineNuxtConfig({
 
 #### What Changed
 
-The order in which modules are loaded when using [Nuxt layers](/docs/4.x/guide/going-further/layers) has been corrected. Previously, modules from the project root were loaded before modules from extended layers, which was the reverse of the expected behavior.
+The order in which modules are loaded when using [Nuxt layers](/docs/guide/going-further/layers) has been corrected. Previously, modules from the project root were loaded before modules from extended layers, which was the reverse of the expected behavior.
 
 Now modules are loaded in the correct order:
 
@@ -639,7 +439,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/4.x/guide/modules/recipes-advanced) 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/guide/modules/recipes-advanced) 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.
 
@@ -1594,7 +1394,7 @@ In the table below, there is a quick comparison between 3 versions of Nuxt:
 
 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/4.x/migration/overview"}
+::read-more{to="/docs/migration/overview"}
 Check out the **guide to migrating from Nuxt 2 to Nuxt 3**.
 ::
 
@@ -1602,6 +1402,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/4.x/bridge/overview"}
+::read-more{to="/docs/bridge/overview"}
 **Migrate from Nuxt 2 to Nuxt Bridge**
 ::

package/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/4.x/directory-structure/gitignore) file to avoid pushing the dev build output to your repository.
+This directory should be added to your [`.gitignore`](/docs/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.
@@ -16,5 +16,5 @@ Nuxt also provides a Virtual File System (VFS) for modules to add templates to t
 You can explore the generated files by opening the [Nuxt DevTools](https://devtools.nuxt.com) in development mode and navigating to the **Virtual Files** tab.
 
 ::warning
-You should not touch any files inside since the whole directory will be re-created when running [`nuxt dev`](/docs/4.x/api/commands/dev).
+You should not touch any files inside since the whole directory will be re-created when running [`nuxt dev`](/docs/api/commands/dev).
 ::

package/2.directory-structure/0.output.md

@@ -6,13 +6,13 @@ navigation.icon: i-vscode-icons-folder-type-package
 ---
 
 ::important
-This directory should be added to your [`.gitignore`](/docs/4.x/directory-structure/gitignore) file to avoid pushing the build output to your repository.
+This directory should be added to your [`.gitignore`](/docs/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/4.x/getting-started/deployment"}
+:read-more{to="/docs/getting-started/deployment"}
 
 ::warning
-You should not touch any files inside since the whole directory will be re-created when running [`nuxt build`](/docs/4.x/api/commands/build).
+You should not touch any files inside since the whole directory will be re-created when running [`nuxt build`](/docs/api/commands/build).
 ::

package/2.directory-structure/1.app/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/4.x/directory-structure/public) directory.
+- Images that won't be served from the [`public/`](/docs/directory-structure/public) directory.
 
-If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/4.x/directory-structure/public) directory.
+If you want to serve assets from the server, we recommend taking a look at the [`public/`](/docs/directory-structure/public) directory.
 
-:read-more{to="/docs/4.x/getting-started/assets"}
+:read-more{to="/docs/getting-started/assets"}