@nuxt/docs-nightly 5.0.0-29837393.f0553e4c → 5.0.0-29837688.ef8d0fbb

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

@@ -158,7 +158,7 @@ You can control this behavior with the [`experimental.payloadExtraction`](/docs/
 - `true` - The payload is extracted to a separate `_payload.json` file for both the initial render and client-side navigation. The HTML is smaller and the payload file can be cached by a CDN, at the cost of one extra request on first load.
 - `false` - Payload extraction is disabled. The payload is always inlined in the HTML and no `_payload.json` files are generated.
 
-The default is `true`, or `'client'` when `compatibilityVersion: 5` is set. It is forced to `false` when `ssr: false` is set.
+The default is `'client'`. It is forced to `false` when `ssr: false` is set.
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({

package/3.guide/5.recipes/1.custom-routing.md

@@ -138,7 +138,7 @@ export default defineNuxtConfig({
 ```
 
 ::note
-With `future.compatibilityVersion: 5`, routing is case-sensitive by default to match Nitro. Set `router.options.sensitive` to `false` to opt out.
+Routing is case-sensitive by default to match Nitro. Set `router.options.sensitive` to `false` to opt out.
 ::
 
 ### Hash Mode (SPA)

package/3.guide/6.going-further/1.experimental-features.md

@@ -193,23 +193,14 @@ export default defineNuxtConfig({
 ## parseErrorData
 
 ::warning
-This option is deprecated and will be removed. With `compatibilityVersion: 5` it is forced on and setting it is ignored.
+This option is deprecated and will be removed. It is forced on and setting it is ignored.
 ::
 
 Whether to parse `error.data` when rendering a server error page.
 
 It existed because the error was previously passed to the error page as individual query parameters, which stringified `error.data` and meant it had to be parsed back. Setting it to `false` opted out of that parsing and left you with the string.
 
-The error is now JSON-encoded as a whole, so `error.data` arrives with its original shape and is never stringified. On `compatibilityVersion: 4`, setting this to `false` stringifies it again so existing error pages that call `JSON.parse(error.data)` keep working:
-
-```ts twoslash [nuxt.config.ts]
-export default defineNuxtConfig({
-  future: { compatibilityVersion: 4 },
-  experimental: {
-    parseErrorData: false,
-  },
-})
-```
+The error is now JSON-encoded as a whole, so `error.data` arrives with its original shape and is never stringified.
 
 ## payloadExtraction
 
@@ -219,7 +210,7 @@ Controls how payload data is delivered for prerendered and cached (ISR/SWR) page
 - `true` - Payload is extracted to a separate `_payload.json` file for both the initial server render and client-side navigation.
 - `false` - Payload extraction is disabled entirely. Payload is always inlined in HTML and no `_payload.json` files are generated.
 
-The default is `true`, or `'client'` when `compatibilityVersion: 5` is set. It is forced to `false` when `ssr: false` is set.
+The default is `'client'`. It is forced to `false` when `ssr: false` is set.
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
@@ -243,12 +234,12 @@ When enabled, `.client.vue` components and `createClientOnly()` wrappers render
 Enabling this means attributes (`class`, `style`, etc.) passed to `.client.vue` components will not appear in the SSR HTML. If you need styled placeholders to prevent layout shift, use `<ClientOnly>` with a `#fallback` slot instead.
 ::
 
-This flag is enabled when `future.compatibilityVersion` is set to `5` or higher, but you can also enable it explicitly:
+This flag is enabled by default, but you can disable it:
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
   experimental: {
-    clientNodePlaceholder: true,
+    clientNodePlaceholder: false,
   },
 })
 ```
@@ -478,8 +469,7 @@ You can also set this to `chokidar` to watch all files in your source directory.
 
 Set to `'builder'` to reuse the active builder's own file watcher (for example,
 Vite's `server.watcher`) instead of starting a second one. This reduces the
-number of file watchers active in dev mode and becomes the default when
-`future.compatibilityVersion` is `5`. If the active builder does not implement
+number of file watchers active in dev mode and is the default. If the active builder does not implement
 its own watcher (currently webpack and rspack), Nuxt logs a warning and falls
 back to its default selection.
 
@@ -656,7 +646,7 @@ This allows modules to access additional metadata from the page metadata in the
 
 ## extractSerializablePageMeta
 
-Enabled by default when `future.compatibilityVersion` is `5` or higher.
+Enabled by default.
 
 By default, Nuxt only reads a fixed list of `definePageMeta()` keys at build time (plus anything in `extraPageMetaExtractionKeys`); everything else is resolved at runtime from a separate module generated per page. With this option, Nuxt writes every JSON-serializable property straight into the generated route record instead.
 
@@ -705,7 +695,7 @@ Transform top-level `await navigateTo()` calls in `<script setup>` into an early
 
 Without this flag, code after `await navigateTo()` continues to run, which can result in later code (including subsequent `navigateTo` calls) overriding the redirect or attempting to render a page with missing data. With this flag enabled, a successful navigation stops execution of the rest of your setup code and the component renders a placeholder comment while the navigation proceeds.
 
-This flag is enabled by default with `compatibilityVersion: 5`, but you can disable it:
+This flag is enabled by default, but you can disable it:
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
@@ -773,7 +763,7 @@ By default, Vue assigns component names based on the filename. For example, `pag
 
 With `normalizePageNames` enabled, page components are named after their route (e.g. `foo` and `bar`), so you can use `<KeepAlive>` with `include`/`exclude` without manually adding `defineOptions({ name: '...' })` to each page.
 
-This flag is enabled when `future.compatibilityVersion` is set to `5` or higher, but you can disable this feature:
+This flag is enabled by default, but you can disable this feature:
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({
@@ -992,7 +982,7 @@ export default defineNuxtConfig({
 })
 ```
 
-The `useState.resetOnClear` option controls whether [`clearNuxtState`](/docs/api/utils/clear-nuxt-state) resets state to its initial value (provided by the `init` function of [`useState`](/docs/api/composables/use-state)) instead of setting it to `undefined`. This defaults to `true` with `compatibilityVersion: 5`.
+The `useState.resetOnClear` option controls whether [`clearNuxtState`](/docs/api/utils/clear-nuxt-state) resets state to its initial value (provided by the `init` function of [`useState`](/docs/api/composables/use-state)) instead of setting it to `undefined`. This defaults to `true`.
 
 ## purgeCachedData
 

package/3.guide/6.going-further/1.features.md

@@ -95,22 +95,8 @@ See the mostly-static site recipe for combining `noScripts` with prerendering, i
 
 There is also a `future` namespace for early opting-in to new features that will become default in a future (possibly major) version of the framework.
 
-### compatibilityVersion
-
-This enables early access to Nuxt features or flags.
-
-On Nuxt 5 it resolves to `5`, and the defaults described in the upgrade guide apply. Individual changes are configured through the options named there rather than through this one.
-
-```ts
-export default defineNuxtConfig({
-  future: {
-    compatibilityVersion: 5,
-  },
-})
-```
-
-::read-more{to="/docs/getting-started/upgrade#migrating-to-nuxt-5"}
-Learn more about migrating to Nuxt 5.
+::note
+`future.compatibilityVersion` always resolves to `5` in Nuxt 5. To opt into Nuxt 5 behaviour on Nuxt 4, see the [Nuxt 4 documentation](https://nuxt.com/docs/4.x/getting-started/upgrade#testing-nuxt-5).
 ::
 
 ### multiApp

package/4.api/2.composables/use-server-seo-meta.md

@@ -9,7 +9,7 @@ links:
 ---
 
 ::warning
-`useServerSeoMeta` is deprecated. Wrap [`useSeoMeta`](/docs/api/composables/use-seo-meta) in an `if (import.meta.server)` block instead. The auto-import is removed under `future.compatibilityVersion: 5`.
+`useServerSeoMeta` is deprecated. Wrap [`useSeoMeta`](/docs/api/composables/use-seo-meta) in an `if (import.meta.server)` block instead. It is no longer auto-imported.
 ::
 
 `useServerSeoMeta` lets you define your site's SEO meta tags as a flat object with full TypeScript support, exactly like [`useSeoMeta`](/docs/api/composables/use-seo-meta), but it only runs server-side and is tree-shaken from the client bundle.

package/4.api/3.utils/clear-nuxt-state.md

@@ -23,4 +23,4 @@ export function clearNuxtState (keys?: string | string[] | ((key: string) => boo
 
 - `keys`: One or an array of keys that are used in [`useState`](/docs/api/composables/use-state) to delete their cached state. If no keys are provided, **all state** will be invalidated.
 - `opts`: An options object to configure the clear behavior.
-  - `reset` :badge[v4.4]{color="info" size="xs" class="align-middle"}: When set to `true`, resets the state to the initial value provided by the `init` function of [`useState`](/docs/api/composables/use-state) instead of setting it to `undefined`. When not specified, defaults to the value of `experimental.defaults.useState.resetOnClear` in your Nuxt config (which is `true` with `compatibilityVersion: 5`).
+  - `reset` :badge[v4.4]{color="info" size="xs" class="align-middle"}: When set to `true`, resets the state to the initial value provided by the `init` function of [`useState`](/docs/api/composables/use-state) instead of setting it to `undefined`. When not specified, defaults to the value of `experimental.defaults.useState.resetOnClear` in your Nuxt config (which defaults to `true`).

package/4.api/6.advanced/2.import-meta.md

@@ -19,7 +19,7 @@ Read more about `import.meta`.
 These values are statically injected and can be used for tree-shaking your runtime code.
 
 ::note
-`process.browser`, `process.client`, `process.dev`, `process.server`, and `process.test` were soft-deprecated in Nuxt 3.12. In Nuxt 5 or with `future.compatibilityVersion: 5`, Nuxt no longer augments `NodeJS.Process` with those properties. Prefer the matching `import.meta.*` flags; build-time `process.*` defines still exist for compatibility.
+`process.browser`, `process.client`, `process.dev`, `process.server`, and `process.test` were soft-deprecated in Nuxt 3.12. In Nuxt 5, Nuxt no longer augments `NodeJS.Process` with those properties. Prefer the matching `import.meta.*` flags; build-time `process.*` defines still exist for compatibility.
 ::
 
 Property | Type | Description

package/4.api/6.nuxt-config.md

@@ -1605,6 +1605,17 @@ If set to true, this will type check in development. You can restrict this to bu
 
 **See**: [Nuxt TypeScript docs](/docs/guide/concepts/typescript)
 
+## typesDir
+
+Define the directory where generated types and `tsconfig.json` files will be placed.
+
+This defaults to your `buildDir`, and is separate from it so that the configurations referenced by your project `tsconfig.json` stay in place even when Nuxt builds elsewhere (as it does when building a project that has already been run in development).
+
+If a relative path is specified, it will be relative to your `rootDir`.
+
+- **Type**: `string`
+- **Default:** `"/<rootDir>/.nuxt"`
+
 ## unhead
 
 An object that allows us to configure the `unhead` nuxt module.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nuxt/docs-nightly",
-  "version": "5.0.0-29837393.f0553e4c",
+  "version": "5.0.0-29837688.ef8d0fbb",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/nuxt/nuxt.git",