@nuxt/docs 4.0.0-0 → 4.0.0-alpha.1

package/1.getting-started/01.introduction.md

@@ -72,9 +72,9 @@ A module system allows to extend Nuxt with custom features and integrations with
 
 Nuxt is composed of different [core packages](https://github.com/nuxt/nuxt/tree/main/packages):
 
-- Core Engine: [nuxt](https://github.com/nuxt/nuxt/tree/main/packages/nuxt)
-- Bundlers: [@nuxt/vite-builder](https://github.com/nuxt/nuxt/tree/main/packages/vite) and [@nuxt/webpack-builder](https://github.com/nuxt/nuxt/tree/main/packages/webpack)
-- Command line interface: [nuxi](https://github.com/nuxt/nuxt/tree/main/packages/nuxi)
+- Core engine: [nuxt](https://github.com/nuxt/nuxt/tree/main/packages/nuxt)
+- Bundlers: [@nuxt/vite-builder](https://github.com/nuxt/nuxt/tree/main/packages/vite), [@nuxt/rspack-builder](https://github.com/nuxt/nuxt/tree/main/packages/rspack) and [@nuxt/webpack-builder](https://github.com/nuxt/nuxt/tree/main/packages/webpack)
+- Command line interface: [@nuxt/cli](https://github.com/nuxt/cli)
 - Server engine: [nitro](https://github.com/nitrojs/nitro)
 - Development kit: [@nuxt/kit](https://github.com/nuxt/nuxt/tree/main/packages/kit)
 

package/1.getting-started/02.installation.md

@@ -21,7 +21,7 @@ Or follow the steps below to set up a new Nuxt project on your computer.
 <!-- markdownlint-disable-next-line MD001 -->
 #### Prerequisites
 
-- **Node.js** - [`18.x`](https://nodejs.org/en) or newer (but we recommend the [active LTS release](https://github.com/nodejs/release#release-schedule))
+- **Node.js** - [`20.x`](https://nodejs.org/en) or newer (but we recommend the [active LTS release](https://github.com/nodejs/release#release-schedule))
 - **Text editor** - There is no IDE requirement, but we recommend [Visual Studio Code](https://code.visualstudio.com/) with the [official Vue extension](https://marketplace.visualstudio.com/items?itemName=Vue.volar) (previously known as Volar) or [WebStorm](https://www.jetbrains.com/webstorm/), which, along with [other JetBrains IDEs](https://www.jetbrains.com/ides/), offers great Nuxt support right out-of-the-box.
 - **Terminal** - In order to run Nuxt commands
 

package/1.getting-started/03.configuration.md

@@ -50,7 +50,7 @@ export default defineNuxtConfig({
 })
 ```
 
-To select an environment when running a Nuxt CLI command, simply pass the name to the `--envName` flag, like so: `nuxi build --envName staging`.
+To select an environment when running a Nuxt CLI command, simply pass the name to the `--envName` flag, like so: `nuxt build --envName staging`.
 
 To learn more about the mechanism behind these overrides, please refer to the `c12` documentation on [environment-specific configuration](https://github.com/unjs/c12?tab=readme-ov-file#environment-specific-configuration).
 
@@ -171,8 +171,8 @@ Name                                         | Config File             | How To
 
 If you need to pass options to `@vitejs/plugin-vue` or `@vitejs/plugin-vue-jsx`, you can do this in your `nuxt.config` file.
 
-- `vite.vue` for `@vitejs/plugin-vue`. Check available options [here](https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue).
-- `vite.vueJsx` for `@vitejs/plugin-vue-jsx`. Check available options [here](https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue-jsx).
+- `vite.vue` for `@vitejs/plugin-vue`. Check [available options](https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue).
+- `vite.vueJsx` for `@vitejs/plugin-vue-jsx`. Check [available options](https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue-jsx).
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({

package/1.getting-started/06.styling.md

@@ -145,7 +145,7 @@ useHead({
 })
 ```
 
-Nuxt uses `unhead` under the hood, and you can refer to its full documentation [here](https://unhead.unjs.io).
+Nuxt uses `unhead` under the hood, and you can refer to [its full documentation](https://unhead.unjs.io).
 
 ### Modifying The Rendered Head With A Nitro Plugin
 

package/1.getting-started/07.routing.md

@@ -94,7 +94,7 @@ There are three kinds of route middleware:
 
 1. Anonymous (or inline) route middleware, which are defined directly in the pages where they are used.
 2. Named route middleware, which are placed in the [`middleware/`](/docs/guide/directory-structure/middleware) directory and will be automatically loaded via asynchronous import when used on a page. (**Note**: The route middleware name is normalized to kebab-case, so `someMiddleware` becomes `some-middleware`.)
-3. Global route middleware, which are placed in the [`middleware/` directory](/docs/guide/directory-structure/middleware) (with a `.global` suffix) and will be automatically run on every route change.
+3. Global route middleware, which are placed in the [`middleware/`](/docs/guide/directory-structure/middleware) directory (with a `.global` suffix) and will be automatically run on every route change.
 
 Example of an `auth` middleware protecting the `/dashboard` page:
 

package/1.getting-started/11.state-management.md

@@ -84,7 +84,7 @@ This is similar to the [`nuxtServerInit` action](https://v2.nuxt.com/docs/direct
 In this example, we leverage the [Pinia module](/modules/pinia) to create a global store and use it across the app.
 
 ::important
-Make sure to install the Pinia module with `npx nuxi@latest module add pinia` or follow the [module's installation steps](https://pinia.vuejs.org/ssr/nuxt.html#Installation).
+Make sure to install the Pinia module with `npx nuxt module add pinia` or follow the [module's installation steps](https://pinia.vuejs.org/ssr/nuxt.html#Installation).
 ::
 
 ::code-group

package/1.getting-started/12.error-handling.md

@@ -99,7 +99,7 @@ const handleError = () => clearError({ redirect: '/' })
 
 <template>
   <div>
-    <h2>{{ error.statusCode }}</h2>
+    <h2>{{ error?.statusCode }}</h2>
     <button @click="handleError">Clear errors</button>
   </div>
 </template>

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

@@ -10,26 +10,26 @@ Nuxt allows for select pages from your application to be rendered at build time.
 
 ## Crawl-based Pre-rendering
 
-Use the [`nuxi generate` command](/docs/api/commands/generate) to build and pre-render your application using the [Nitro](/docs/guide/concepts/server-engine) crawler. This command is similar to `nuxt build` with the `nitro.static` option set to `true`, or running `nuxt build --prerender`.
+Use the [`nuxt generate` command](/docs/api/commands/generate) to build and pre-render your application using the [Nitro](/docs/guide/concepts/server-engine) crawler. This command is similar to `nuxt build` with the `nitro.static` option set to `true`, or running `nuxt build --prerender`.
 
 This will build your site, stand up a nuxt instance, and, by default, prerender the root page `/` along with any of your site's pages it links to, any of your site's pages they link to, and so on.
 
 ::code-group{sync="pm"}
 
 ```bash [npm]
-npx nuxi generate
+npx nuxt generate
 ```
 
 ```bash [yarn]
-yarn dlx nuxi generate
+yarn nuxt generate
 ```
 
 ```bash [pnpm]
-pnpm dlx nuxi generate
+pnpm nuxt generate
 ```
 
 ```bash [bun]
-bun x nuxi generate
+bun x nuxt generate
 ```
 
 ::
@@ -45,8 +45,8 @@ 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#nuxi-generate"}
-Read more about the `nuxi generate` command.
+::read-more{to="/docs/api/commands/generate#nuxt-generate"}
+Read more about the `nuxt generate` command.
 ::
 
 ### Selective Pre-rendering

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

@@ -70,14 +70,14 @@ By default, the workload gets distributed to the workers with the round robin st
 
 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 `nuxi 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).
+- 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/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"}
 
 ### Client-side Only Rendering
 
-If you don't want to pre-render your routes, another way of using static hosting is to set the `ssr` property to `false` in the `nuxt.config` file. The `nuxi generate` command will then output an `.output/public/index.html` entrypoint and JavaScript bundles like a classic client-side Vue.js application.
+If you don't want to pre-render your routes, another way of using static hosting is to set the `ssr` property to `false` in the `nuxt.config` file. The `nuxt generate` command will then output an `.output/public/index.html` entrypoint and JavaScript bundles like a classic client-side Vue.js application.
 
 ```ts twoslash [nuxt.config.ts]
 export default defineNuxtConfig({

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

@@ -280,7 +280,7 @@ 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 [here](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.html#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.

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

@@ -8,24 +8,24 @@ navigation.icon: i-lucide-circle-arrow-up
 
 ### Latest release
 
-To upgrade Nuxt to the [latest release](https://github.com/nuxt/nuxt/releases), use the `nuxi upgrade` command.
+To upgrade Nuxt to the [latest release](https://github.com/nuxt/nuxt/releases), use the `nuxt upgrade` command.
 
 ::code-group{sync="pm"}
 
 ```bash [npm]
-npx nuxi upgrade
+npx nuxt upgrade
 ```
 
 ```bash [yarn]
-yarn dlx nuxi upgrade
+yarn nuxt upgrade
 ```
 
 ```bash [pnpm]
-pnpm dlx nuxi upgrade
+pnpm nuxt upgrade
 ```
 
 ```bash [bun]
-bun x nuxi upgrade
+bun x nuxt upgrade
 ```
 
 ::
@@ -1019,7 +1019,7 @@ Components Auto Import   | ✅             | ✅                | ✅
 Auto Imports             | ❌             | ✅                | ✅
 webpack                  | 4              | 4                 | 5
 Vite                     | ⚠️ Partial      | 🚧 Partial        | ✅
-Nuxi CLI                 | ❌ Old         | ✅ nuxi           | ✅ nuxi
+Nuxt CLI                 | ❌ Old         | ✅ nuxt           | ✅ nuxt
 Static sites             | ✅             | ✅                | ✅
 
 ## Nuxt 2 to Nuxt 3+

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

@@ -96,10 +96,10 @@ If you do use `ssr: false`, you should also place an HTML file in `~/app/spa-loa
 
 ### Deploying a Static Client-Rendered App
 
-If you deploy your app to [static hosting](/docs/getting-started/deployment#static-hosting) with the `nuxi generate` or `nuxi build --prerender` commands, then by default, Nuxt will render every page as a separate static HTML file.
+If you deploy your app to [static hosting](/docs/getting-started/deployment#static-hosting) with the `nuxt generate` or `nuxt build --prerender` commands, then by default, Nuxt will render every page as a separate static HTML file.
 
 ::warning
-If you prerender your app with the `nuxi generate` or `nuxi build --prerender` commands, then you will not be able to use any server endpoints as no server will be included in your output folder. If you need server functionality, use `nuxi build` instead.
+If you prerender your app with the `nuxt generate` or `nuxt build --prerender` commands, then you will not be able to use any server endpoints as no server will be included in your output folder. If you need server functionality, use `nuxt build` instead.
 ::
 
 If you are using purely client-side rendering, then this might be unnecessary. You might only need a single `index.html` file, plus `200.html` and `404.html` fallbacks, which you can tell your static web host to serve up for all requests.

package/2.guide/1.concepts/5.modules.md

@@ -7,7 +7,7 @@ description: "Nuxt provides a module system to extend the framework core and sim
 
 When developing production-grade applications with Nuxt you might find that the framework's core functionality is not enough. Nuxt can be extended with configuration options and plugins, but maintaining these customizations across multiple projects can be tedious, repetitive and time-consuming. On the other hand, supporting every project's needs out of the box would make Nuxt very complex and hard to use.
 
-This is one of the reasons why Nuxt provides a module system that makes it possible to extend the core. Nuxt modules are async functions that sequentially run when starting Nuxt in development mode using [`nuxi dev`](/docs/api/commands/dev) or building a project for production with [`nuxi build`](/docs/api/commands/build). They can override templates, configure webpack loaders, add CSS libraries, and perform many other useful tasks.
+This is one of the reasons why Nuxt provides a module system that makes it possible to extend the core. Nuxt modules are async functions that sequentially run when starting Nuxt in development mode using [`nuxt dev`](/docs/api/commands/dev) or building a project for production with [`nuxt build`](/docs/api/commands/build). They can override templates, configure webpack loaders, add CSS libraries, and perform many other useful tasks.
 
 Best of all, Nuxt modules can be distributed in npm packages. This makes it possible for them to be reused across projects and shared with the community, helping create an ecosystem of high-quality add-ons.
 

package/2.guide/1.concepts/8.typescript.md

@@ -5,7 +5,7 @@ description: "Nuxt is fully typed and provides helpful shortcuts to ensure you h
 
 ## Type-checking
 
-By default, Nuxt doesn't check types when you run [`nuxi dev`](/docs/api/commands/dev) or [`nuxi build`](/docs/api/commands/build), for performance reasons.
+By default, Nuxt doesn't check types when you run [`nuxt dev`](/docs/api/commands/dev) or [`nuxt build`](/docs/api/commands/build), for performance reasons.
 
 To enable type-checking at build or development time, install `vue-tsc` and `typescript` as development dependency:
 
@@ -29,10 +29,10 @@ To enable type-checking at build or development time, install `vue-tsc` and `typ
 
 ::
 
-Then, run [`nuxi typecheck`](/docs/api/commands/typecheck) command to check your types:
+Then, run [`nuxt typecheck`](/docs/api/commands/typecheck) command to check your types:
 
 ```bash [Terminal]
-npx nuxi typecheck
+npx nuxt typecheck
 ```
 
 To enable type-checking at build or development time, you can also use the [`typescript.typeCheck`](/docs/api/nuxt-config#typecheck) option in your `nuxt.config` file:
@@ -47,13 +47,13 @@ export default defineNuxtConfig({
 
 ## Auto-generated Types
 
-When you run `nuxi dev` or `nuxi build`, Nuxt generates the following files for IDE type support (and type checking):
+When you run `nuxt dev` or `nuxt build`, Nuxt generates the following files for IDE type support (and type checking):
 
 ### `.nuxt/nuxt.d.ts`
 
 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 `nuxi dev` or `nuxi build`.
+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.json`
 
@@ -77,7 +77,7 @@ Nitro also [auto-generates types](/docs/guide/concepts/server-engine#typed-api-r
 Keep in mind that all options extended from `./.nuxt/tsconfig.json` will be overwritten by the options 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 from `./.nuxt/tsconfig.json`. This can lead to module resolutions such as `#imports` not being recognized.
 :br :br
-In case you need to extend options provided by `./.nuxt/tsconfig.json` further, you can use the [`alias` property](/docs/api/nuxt-config#alias) within your `nuxt.config`. `nuxi` will pick them up and extend `./.nuxt/tsconfig.json` accordingly.
+In case you need to extend options provided by `./.nuxt/tsconfig.json` further, you can use the [`alias` property](/docs/api/nuxt-config#alias) within your `nuxt.config`. Nuxt will pick them up and extend `./.nuxt/tsconfig.json` accordingly.
 ::
 
 ## Strict Checks

package/2.guide/1.concepts/9.code-style.md

@@ -14,7 +14,7 @@ The module is designed for the [new ESLint flat config format](https://eslint.or
 ## Quick Setup
 
 ```bash
-npx nuxi module add eslint
+npx nuxt module add eslint
 ```
 
 Start your Nuxt app, a `eslint.config.mjs` file will be generated under your project root. You can customize it as needed.

package/2.guide/2.directory-structure/1.composables.md

@@ -50,7 +50,7 @@ The `composables/` directory in Nuxt does not provide any additional reactivity
 
 Under the hood, Nuxt auto generates the file `.nuxt/imports.d.ts` to declare the types.
 
-Be aware that you have to run [`nuxi prepare`](/docs/api/commands/prepare), [`nuxi dev`](/docs/api/commands/dev) or [`nuxi build`](/docs/api/commands/build) in order to let Nuxt generate the types.
+Be aware that you have to run [`nuxt prepare`](/docs/api/commands/prepare), [`nuxt dev`](/docs/api/commands/dev) or [`nuxt build`](/docs/api/commands/build) in order to let Nuxt generate the types.
 
 ::note
 If you create a composable without having the dev server running, TypeScript will throw an error, such as `Cannot find name 'useBar'.`
@@ -109,12 +109,12 @@ export { utils } from './nested/utils.ts'
 export default defineNuxtConfig({
   imports: {
     dirs: [
-      // Scan top-level modules
-      'composables',
-      // ... or scan modules nested one level deep with a specific name and file extension
-      'composables/*/index.{ts,js,mjs,mts}',
-      // ... or scan all modules within given directory
-      'composables/**'
+      // Scan top-level composables
+      '~/composables',
+      // ... or scan composables nested one level deep with a specific name and file extension
+      '~/composables/*/index.{ts,js,mjs,mts}',
+      // ... or scan all composables within given directory
+      '~/composables/**'
     ]
   }
 })

package/2.guide/2.directory-structure/1.content.md

@@ -21,7 +21,7 @@ Learn more in **Nuxt Content** documentation.
 Install the `@nuxt/content` module in your project as well as adding it to your `nuxt.config.ts` with one command:
 
 ```bash [Terminal]
-npx nuxi module add content
+npx nuxt module add content
 ```
 
 ## Create Content

package/2.guide/2.directory-structure/1.pages.md

@@ -299,13 +299,13 @@ Of course, you are welcome to define metadata for your own use throughout your a
 
 #### `alias`
 
-You can define page aliases. They allow you to access the same page from different paths. It can be either a string or an array of strings as defined [here](https://router.vuejs.org/guide/essentials/redirect-and-alias.html#Alias) on vue-router documentation.
+You can define page aliases. They allow you to access the same page from different paths. It can be either a string or an array of strings as defined [in the vue-router documentation](https://router.vuejs.org/guide/essentials/redirect-and-alias.html#Alias).
 
 #### `keepalive`
 
 Nuxt will automatically wrap your page in [the Vue `<KeepAlive>` component](https://vuejs.org/guide/built-ins/keep-alive.html#keepalive) if you set `keepalive: true` in your `definePageMeta`. This might be useful to do, for example, in a parent route that has dynamic child routes, if you want to preserve page state across route changes.
 
-When your goal is to preserve state for parent routes use this syntax: `<NuxtPage keepalive />`. You can also set props to be passed to `<KeepAlive>` (see a full list [here](https://vuejs.org/api/built-in-components.html#keepalive)).
+When your goal is to preserve state for parent routes use this syntax: `<NuxtPage keepalive />`. You can also set props to be passed to `<KeepAlive>` (see [a full list](https://vuejs.org/api/built-in-components.html#keepalive)).
 
 You can set a default value for this property [in your `nuxt.config`](/docs/api/nuxt-config#keepalive).
 
@@ -319,7 +319,7 @@ You can define the layout used to render the route. This can be either false (to
 
 #### `layoutTransition` and `pageTransition`
 
-You can define transition properties for the `<transition>` component that wraps your pages and layouts, or pass `false` to disable the `<transition>` wrapper for that route. You can see a list of options that can be passed [here](https://vuejs.org/api/built-in-components.html#transition) or read [more about how transitions work](https://vuejs.org/guide/built-ins/transition.html#transition).
+You can define transition properties for the `<transition>` component that wraps your pages and layouts, or pass `false` to disable the `<transition>` wrapper for that route. You can see [a list of options that can be passed](https://vuejs.org/api/built-in-components.html#transition) or read [more about how transitions work](https://vuejs.org/guide/built-ins/transition.html#transition).
 
 You can set default values for these properties [in your `nuxt.config`](/docs/api/nuxt-config#layouttransition).
 
@@ -405,7 +405,7 @@ You can define a page as [client only](/docs/guide/directory-structure/component
 
 You can define a page as [server only](/docs/guide/directory-structure/components#server-components) by giving it a `.server.vue` suffix. While you will be able to navigate to the page using client-side navigation, controlled by `vue-router`, it will be rendered with a server component automatically, meaning the code required to render the page will not be in your client-side bundle.
 
-::alert{type=warning}
+::warning
 Server-only pages must have a single root element. (HTML comments are considered elements as well.)
 ::
 

package/2.guide/2.directory-structure/1.server.md

@@ -144,7 +144,7 @@ To improve clarity within your IDE between the auto-imports from 'nitro' and 'vu
 }
 ```
 
-Currently, these values won't be respected when type checking ([`nuxi typecheck`](/docs/api/commands/typecheck)), but you should get better type hints in your IDE.
+Currently, these values won't be respected when type checking ([`nuxt typecheck`](/docs/api/commands/typecheck)), but you should get better type hints in your IDE.
 
 ## Recipes
 

package/2.guide/2.directory-structure/2.env.md

@@ -11,7 +11,7 @@ This file should be added to your [`.gitignore`](/docs/guide/directory-structure
 
 ## Dev, Build and Generate Time
 
-Nuxt CLI has built-in [dotenv](https://github.com/motdotla/dotenv) support in development mode and when running [`nuxi build`](/docs/api/commands/build) and [`nuxi generate`](/docs/api/commands/generate).
+Nuxt CLI has built-in [dotenv](https://github.com/motdotla/dotenv) support in development mode and when running [`nuxt build`](/docs/api/commands/build) and [`nuxt generate`](/docs/api/commands/generate).
 
 In addition to any process environment variables, if you have a `.env` file in your project root directory, it will be automatically loaded **at dev, build and generate time**. Any environment variables set there will be accessible within your `nuxt.config` file and modules.
 
@@ -25,10 +25,10 @@ Note that removing a variable from `.env` or removing the `.env` file entirely w
 
 ## Custom File
 
-If you want to use a different file - for example, to use `.env.local` or `.env.production` - you can do so by passing the `--dotenv` flag when using `nuxi`.
+If you want to use a different file - for example, to use `.env.local` or `.env.production` - you can do so by passing the `--dotenv` flag when using the Nuxt CLI.
 
 ```bash [Terminal]
-npx nuxi dev --dotenv .env.local
+npx nuxt dev --dotenv .env.local
 ```
 
 When updating `.env` in development mode, the Nuxt instance is automatically restarted to apply new values to the `process.env`.
@@ -57,7 +57,7 @@ Since `.env` files are not used in production, you must explicitly set environme
 
 ## Production Preview
 
-For local production preview purpose, we recommend using [`nuxi preview`](/docs/api/commands/preview) since using this command, the `.env` file will be loaded into `process.env` for convenience. Note that this command requires dependencies to be installed in the package directory.
+For local production preview purpose, we recommend using [`nuxt preview`](/docs/api/commands/preview) since using this command, the `.env` file will be loaded into `process.env` for convenience. Note that this command requires dependencies to be installed in the package directory.
 
 Or you could pass the environment variables as arguments using the terminal. For example, on Linux or macOS:
 

package/2.guide/3.going-further/1.events.md

@@ -74,7 +74,7 @@ declare module '#app' {
   }
 }
 
-declare module 'nitro/types' {
+declare module 'nitropack/types' {
   interface NitroRuntimeHooks {
     'your-nitro-hook': () => void;
   }

package/2.guide/3.going-further/1.internals.md

@@ -7,7 +7,7 @@ This guide helps you better understand Nuxt internals to develop new solutions a
 
 ## The Nuxt Interface
 
-When you start Nuxt in development mode with [`nuxi dev`](/docs/api/commands/dev) or building a production application with [`nuxi build`](/docs/api/commands/build),
+When you start Nuxt in development mode with [`nuxt dev`](/docs/api/commands/dev) or building a production application with [`nuxt build`](/docs/api/commands/build),
 a common context will be created, referred to as `nuxt` internally. It holds normalized options merged with `nuxt.config` file,
 some internal state, and a powerful [hooking system](/docs/api/advanced/hooks) powered by [unjs/hookable](https://github.com/unjs/hookable)
 allowing different components to communicate with each other. You can think of it as **Builder Core**.
@@ -78,4 +78,4 @@ While both areas can be extended, that runtime context is isolated from build-ti
 
 `nuxt.config` and [Nuxt Modules](/docs/guide/going-further/modules) can be used to extend the build context, and [Nuxt Plugins](/docs/guide/directory-structure/plugins) can be used to extend runtime.
 
-When building an application for production, `nuxi build` will generate a standalone build in the `.output` directory, independent of `nuxt.config` and [Nuxt modules](/docs/guide/going-further/modules).
+When building an application for production, `nuxt build` will generate a standalone build in the `.output` directory, independent of `nuxt.config` and [Nuxt modules](/docs/guide/going-further/modules).

package/2.guide/3.going-further/10.runtime-config.md

@@ -44,7 +44,7 @@ Instead of passing non-serializable objects or functions into your application f
 The most common way to provide configuration is by using [Environment Variables](https://medium.com/chingu/an-introduction-to-environment-variables-and-how-to-use-them-f602f66d15fa).
 
 ::note
-Nuxi CLI has built-in support for reading your `.env` file in development, build and generate. But when you run your built server, **your `.env` file will not be read**.
+The Nuxt CLI has built-in support for reading your `.env` file in development, build and generate. But when you run your built server, **your `.env` file will not be read**.
 :read-more{to="/docs/guide/directory-structure/env"}
 ::
 

package/2.guide/3.going-further/11.nightly-release-channel.md

@@ -49,16 +49,12 @@ Update `nuxt` dependency inside `package.json`:
 
 Remove lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, or `bun.lockb`) and reinstall dependencies.
 
-## Using Nightly `nuxi`
-
-::note
-All cli dependencies are bundled because of the building method for reducing `nuxi` package size. :br You can get dependency updates and CLI improvements using the nightly release channel.
-::
+## Using Nightly `@nuxt/cli`
 
 To try the latest version of [nuxt/cli](https://github.com/nuxt/cli):
 
 ```bash [Terminal]
-npx nuxi-nightly@latest [command]
+npx @nuxt/cli-nightly@latest [command]
 ```
 
 ::read-more{to="/docs/api/commands"}

package/2.guide/3.going-further/3.modules.md

@@ -6,7 +6,7 @@ image: '/socials/module-author-guide.jpg'
 
 Nuxt's [configuration](/docs/api/nuxt-config) and [hooks](/docs/guide/going-further/hooks) systems make it possible to customize every aspect of Nuxt and add any integration you might need (Vue plugins, CMS, server routes, components, logging, etc.).
 
-**Nuxt Modules** are functions that sequentially run when starting Nuxt in development mode using `nuxi dev` or building a project for production with `nuxi build`.
+**Nuxt Modules** are functions that sequentially run when starting Nuxt in development mode using `nuxt dev` or building a project for production with `nuxt build`.
 With modules, you can encapsulate, properly test, and share custom solutions as npm packages without adding unnecessary boilerplate to your project, or requiring changes to Nuxt itself.
 
 ## Quick Start
@@ -59,7 +59,7 @@ You can interact with the playground like with any Nuxt application.
 - Build it with `npm run dev:build`
 
 ::note
-All other `nuxi` commands can be used against the `playground` directory (e.g. `nuxi <COMMAND> playground`). Feel free to declare additional `dev:*` scripts within your `package.json` referencing them for convenience.
+All other `nuxt` commands can be used against the `playground` directory (e.g. `nuxt <COMMAND> playground`). Feel free to declare additional `dev:*` scripts within your `package.json` referencing them for convenience.
 ::
 
 #### How to Test
@@ -614,7 +614,7 @@ export default defineNuxtModule({
         interface MyModuleNitroRules {
           myModule?: { foo: 'bar' }
         }
-        declare module 'nitro/types' {
+        declare module 'nitropack/types' {
           interface NitroRouteRules extends MyModuleNitroRules {}
           interface NitroRouteConfig extends MyModuleNitroRules {}
         }

package/2.guide/3.going-further/9.debugging.md

@@ -22,7 +22,7 @@ export default defineNuxtConfig({
 You can use [Node inspector](https://nodejs.org/en/learn/getting-started/debugging) to debug Nuxt server-side.
 
 ```bash
-nuxi dev --inspect
+nuxt dev --inspect
 ```
 This will start Nuxt in `dev` mode with debugger active. If everything is working correctly a Node.js icon will appear on your Chrome DevTools and you can attach to the debugger.
 
@@ -38,10 +38,6 @@ It is possible to debug your Nuxt app in your IDE while you are developing it.
 
 You may need to update the config below with a path to your web browser. For more information, visit the [VS Code documentation about debug configuration](https://go.microsoft.com/fwlink/?linkid=830387).
 
-::important
-If you use `pnpm`, you will need to have `nuxi` installed as a devDependency for the configuration below to work.
-::
-
 ```json5
 {
   // Use IntelliSense to learn about possible attributes.

package/2.guide/4.recipes/4.sessions-and-authentication.md

@@ -11,10 +11,10 @@ The module uses secured & sealed cookies to store session data, so you don't nee
 
 ## Install nuxt-auth-utils
 
-Install the `nuxt-auth-utils` module using the `nuxi` CLI.
+Install the `nuxt-auth-utils` module using the `nuxt` CLI.
 
 ```bash [Terminal]
-npx nuxi@latest module add auth-utils
+npx nuxt module add auth-utils
 ```
 
 ::callout

package/3.api/1.components/10.nuxt-picture.md

@@ -19,7 +19,7 @@ Learn more about the [`<picture>` tag on MDN](https://developer.mozilla.org/en-U
 In order to use `<NuxtPicture>` you should install and enable the Nuxt Image module:
 
 ```bash [Terminal]
-npx nuxi@latest module add image
+npx nuxt module add image
 ```
 
 ::read-more{to="https://image.nuxt.com/usage/nuxt-picture" target="_blank"}

package/3.api/1.components/9.nuxt-img.md

@@ -21,7 +21,7 @@ links:
 In order to use `<NuxtImg>` you should install and enable the Nuxt Image module:
 
 ```bash [Terminal]
-npx nuxi@latest module add image
+npx nuxt module add image
 ```
 
 ## Usage

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

@@ -98,7 +98,7 @@ The `handler` function should be **side-effect free** to ensure predictable beha
     Which only caches data when `experimental.payloadExtraction` of `nuxt.config` is enabled.
   - `pick`: only pick specified keys in this array from the `handler` function result
   - `watch`: watch reactive sources to auto-refresh
-  - `deep`: return data in a deep ref object. It is `false` by default to return data in a shallow ref object for performance.
+  - `deep`: return data in a deep ref object. It is `false` by default to return data in a shallow ref object, which can improve performance if your data does not need to be deeply reactive.
   - `dedupe`: avoid fetching same key more than once at a time (defaults to `cancel`). Possible options:
     - `cancel` - cancels existing requests when a new one is made
     - `defer` - does not make new requests at all if there is a pending request

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

@@ -132,7 +132,7 @@ All fetch options can be given a `computed` or `ref` value. These will be watche
     Which only caches data when `experimental.payloadExtraction` of `nuxt.config` is enabled.
   - `pick`: only pick specified keys in this array from the `handler` function result
   - `watch`: watch an array of reactive sources and auto-refresh the fetch result when they change. Fetch options and URL are watched by default. You can completely ignore reactive sources by using `watch: false`. Together with `immediate: false`, this allows for a fully-manual `useFetch`. (You can [see an example here](/docs/getting-started/data-fetching#watch) of using `watch`.)
-  - `deep`: return data in a deep ref object. It is `false` by default to return data in a shallow ref object for performance.
+  - `deep`: return data in a deep ref object. It is `false` by default to return data in a shallow ref object, which can improve performance if your data does not need to be deeply reactive.
   - `dedupe`: avoid fetching same key more than once at a time (defaults to `cancel`). Possible options:
     - `cancel` - cancels existing requests when a new one is made
     - `defer` - does not make new requests at all if there is a pending request

package/3.api/2.composables/use-preview-mode.md

@@ -103,8 +103,8 @@ const { data } = await useFetch('/api/preview', {
 Now you can generate your site and serve it:
 
 ```bash [Terminal]
-npx nuxi generate
-npx nuxi preview
+npx nuxt generate
+npx nuxt preview
 ```
 
 Then you can see your preview page by adding the query param `preview` to the end of the page you want to see once:
@@ -114,5 +114,5 @@ Then you can see your preview page by adding the query param `preview` to the en
 ```
 
 ::note
-`usePreviewMode` should be tested locally with `nuxi generate` and then `nuxi preview` rather than `nuxi dev`. (The [preview command](/docs/api/commands/preview) is not related to preview mode.)
+`usePreviewMode` should be tested locally with `nuxt generate` and then `nuxt preview` rather than `nuxt dev`. (The [preview command](/docs/api/commands/preview) is not related to preview mode.)
 ::