@nuxt/docs-nightly 4.4.7-29673476.91186dc5 → 4.4.8-29682245.e6d578fe

package/1.getting-started/10.data-fetching.md

@@ -241,7 +241,7 @@ Read more about `useAsyncData`.
 By default, Nuxt waits until a `refresh` is finished before it can be executed again.
 
 ::note
-If you have not fetched data on the server (for example, with `server: false`), then the data _will not_ be fetched until hydration completes. This means even if you await `useFetch` on client-side, `data` will remain null within `<script setup>`.
+If you have not fetched data on the server (for example, with `server: false`), then the data _will not_ be fetched until hydration completes. This means even if you await `useFetch` on client-side, `data` will remain undefined within `<script setup>`.
 ::
 
 ## Options
@@ -541,7 +541,7 @@ const pending = computed(() => status.value === 'pending')
     >
 
     <div v-if="status === 'idle'">
-      Type an user ID
+      Type a user ID
     </div>
 
     <div v-else-if="pending">

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

@@ -80,6 +80,25 @@ 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/4.x/api/components/client-only) to wrap the portions of your site that cannot be server rendered (if any).
 
+### Static Fallback Pages
+
+Nuxt can generate two fallback pages for static hosts:
+
+- `200.html` is the single-page app fallback. Configure your host to serve it for unmatched routes when you want client-side routing to handle the URL.
+- `404.html` is the not-found fallback. Configure your host to serve it for routes that should keep a 404 status.
+
+`nuxt generate` and `nuxt build --prerender` generate these files automatically. If you use `nuxt build` with route rules to prerender selected routes, add the fallback page explicitly:
+
+```ts twoslash [nuxt.config.ts]
+export default defineNuxtConfig({
+  routeRules: {
+    '/200.html': { prerender: true },
+  },
+})
+```
+
+Some providers use `200.html`, some use `404.html`, and some let you configure both. Check your hosting provider's static fallback or rewrite settings after deployment.
+
 :read-more{title="Nuxt prerendering" to="/docs/4.x/getting-started/prerendering"}
 
 ### Client-side Only Rendering

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

@@ -124,7 +124,7 @@ This will produce three files:
 - `200.html`
 - `404.html`
 
-The `200.html` and `404.html` might be useful for the hosting provider you are using.
+The `200.html` file is intended for static hosts that need a success-status fallback for client-side routing. The `404.html` file is intended for static hosts that serve a not-found page while preserving a 404 status. Which file you should use depends on your hosting provider's fallback or rewrite settings.
 
 #### Skipping Client Fallback Generation
 

package/3.guide/2.best-practices/performance.md

@@ -218,7 +218,7 @@ To improve performance, we need to first know how to measure it, starting with m
 
 ### Nuxi Analyze
 
-[This](/docs/4.x/api/commands/analyze) command of `nuxi` allows to analyze the production bundle or your Nuxt application. It leverages `vite-bundle-visualizer` (similar to `webpack-bundle-analyzer`) to generate a visual representation of your application's bundle, making it easier to identify which components take up the most space.
+[This](/docs/4.x/api/commands/analyze) command of `nuxi` allows you to analyze the production bundle of your Nuxt application. It leverages `vite-bundle-visualizer` (similar to `webpack-bundle-analyzer`) to generate a visual representation of your application's bundle, making it easier to identify which components take up the most space.
 
 When you see a large block in the visualization, it often signals an opportunity for optimization—whether by splitting it into smaller parts, implementing lazy loading, or replacing it with a more efficient alternative, especially for third-party libraries.
 

package/3.guide/4.modules/5.recipes-advanced.md

@@ -239,5 +239,5 @@ Server routes are also type-checked using `tsconfig.app.json` in addition to `ts
 This is required because Nuxt infers the return types of your server endpoints to provide response types in [`$fetch`](/docs/4.x/api/utils/dollarfetch) and [`useFetch`](/docs/4.x/api/composables/use-fetch).
 
 ::warning
-This can cause issues when using **server-only types** in your route files. For example, if a module creates a server-only virtual file using [`addServerTemplate`](/docs/api/kit/templates#addservertemplate) and you declare types for it in `tsconfig.server.json`, those type declarations will only be available in the server context. When the app context type-checks your server routes, it won't recognize these server-only types and will report errors.  To resolve this, you unfortunately need to declare such types in the app context as well.
+This can cause issues when using **server-only types** in your route files. For example, if a module creates a server-only virtual file using [`addServerTemplate`](/docs/4.x/api/kit/templates#addservertemplate) and you declare types for it in `tsconfig.server.json`, those type declarations will only be available in the server context. When the app context type-checks your server routes, it won't recognize these server-only types and will report errors.  To resolve this, you unfortunately need to declare such types in the app context as well.
 ::

package/4.api/2.composables/use-announcer.md

@@ -14,7 +14,7 @@ This composable is available in Nuxt v4.4.2+.
 
 ## Description
 
-A composable for announcing dynamic content changes to screen readers. Unlike [`useRouteAnnouncer`](/docs/api/composables/use-route-announcer) which automatically announces route changes, `useAnnouncer` gives you manual control over what and when to announce.
+A composable for announcing dynamic content changes to screen readers. Unlike [`useRouteAnnouncer`](/docs/4.x/api/composables/use-route-announcer) which automatically announces route changes, `useAnnouncer` gives you manual control over what and when to announce.
 
 Use this for in-page updates like form validation, async operations, toast notifications, and live content changes.
 

package/4.api/2.composables/use-async-data.md

@@ -251,7 +251,7 @@ type AsyncDataOptions<DataT> = {
   default?: () => DataT | Ref<DataT> | null
   transform?: (input: DataT) => DataT | Promise<DataT>
   pick?: string[]
-  watch?: MultiWatchSources | false
+  watch?: MultiWatchSources
   getCachedData?: (key: string, nuxtApp: NuxtApp, ctx: AsyncDataRequestContext) => DataT | undefined
   timeout?: number
 }

package/4.api/2.composables/use-error.md

@@ -23,10 +23,11 @@ You can use this composable in your components, pages, or plugins to access or r
 ```ts
 interface NuxtError<DataT = unknown> {
   status: number
-  statusText: string
+  statusText?: string
   message: string
   data?: DataT
-  error?: true
+  cause?: unknown
+  fatal: boolean
 }
 
 export const useError: () => Ref<NuxtError | undefined>

package/4.api/2.composables/use-fetch.md

@@ -240,7 +240,7 @@ This only caches data when `experimental.payloadExtraction` in `nuxt.config` is
 - `error`: Request failed
 
 ::note
-If you have not fetched data on the server (for example, with `server: false`), then the data _will not_ be fetched until hydration completes. This means even if you await `useFetch` on client-side, `data` will remain null within `<script setup>`.
+If you have not fetched data on the server (for example, with `server: false`), then the data _will not_ be fetched until hydration completes. This means even if you await `useFetch` on client-side, `data` will remain undefined within `<script setup>`.
 ::
 
 ### Examples

package/4.api/2.composables/use-nuxt-data.md

@@ -28,7 +28,7 @@ To use `useNuxtData`, ensure that the data-fetching composable (`useFetch`, `use
 
 ## Return Values
 
-- `data`: A reactive reference to the cached data associated with the provided key. If no cached data exists, the value will be `null`. This `Ref` automatically updates if the cached data changes, allowing seamless reactivity in your components.
+- `data`: A reactive reference to the cached data associated with the provided key. If no cached data exists, the value will be `undefined`. This `Ref` automatically updates if the cached data changes, allowing seamless reactivity in your components.
 
 ## Example
 

package/4.api/4.commands/test.md

@@ -14,7 +14,7 @@ npx nuxt test [ROOTDIR] [--cwd=<directory>] [--logLevel=<silent|info|verbose>] [
 ```
 <!--/test-cmd-->
 
-The `test` command runs tests using [`@nuxt/test-utils`](/docs/getting-started/testing). This command sets `process.env.NODE_ENV` to `test` if not already set.
+The `test` command runs tests using [`@nuxt/test-utils`](/docs/4.x/getting-started/testing). This command sets `process.env.NODE_ENV` to `test` if not already set.
 
 ## Arguments
 

package/4.api/5.kit/7.pages.md

@@ -65,7 +65,7 @@ You can read more about Nitro route rules in the [Nitro documentation](https://n
 ::
 
 ::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/adding-route-rules-and-route-middlewares?friend=nuxt" target="_blank"}
-Watch Vue School video about adding route rules and route middelwares.
+Watch Vue School video about adding route rules and route middlewares.
 ::
 
 ### Usage
@@ -116,7 +116,7 @@ function extendRouteRules (route: string, rule: NitroRouteConfig, options?: Exte
 About route rules configurations, you can get more detail in [Hybrid Rendering > Route Rules](/docs/4.x/guide/concepts/rendering#route-rules).
 ::
 
-**options**: A object to pass to the route configuration. If `override` is set to `true`, it will override the existing route configuration.
+**options**: An object to pass to the route configuration. If `override` is set to `true`, it will override the existing route configuration.
 
 | Name       | Type      | Default | Description                                  |
 | ---------- | --------- | ------- | -------------------------------------------- |
@@ -133,7 +133,7 @@ Read more about route middlewares in the [Route middleware documentation](/docs/
 ::
 
 ::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/adding-route-rules-and-route-middlewares?friend=nuxt" target="_blank"}
-Watch Vue School video about adding route rules and route middelwares.
+Watch Vue School video about adding route rules and route middlewares.
 ::
 
 ### Usage

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nuxt/docs-nightly",
-  "version": "4.4.7-29673476.91186dc5",
+  "version": "4.4.8-29682245.e6d578fe",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/nuxt/nuxt.git",