@nuxt/docs-nightly 4.2.3-29422039.47e05245 → 4.2.3-29425455.7d502292

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

@@ -0,0 +1,231 @@
+---
+title: "Use Hooks & Extend Types"
+description: "Master lifecycle hooks, virtual files and TypeScript declarations in your modules."
+---
+
+Here are some advanced patterns for authoring modules, including hooks, templates, and type augmentation.
+
+## Use Lifecycle Hooks
+
+[Lifecycle hooks](/docs/4.x/guide/going-further/hooks) allow you to expand almost every aspect of Nuxt. Modules can hook to them programmatically or through the `hooks` map in their definition.
+
+```js
+import { addPlugin, createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  // Hook to the `app:error` hook through the `hooks` map
+  hooks: {
+    'app:error': (err) => {
+      console.info(`This error happened: ${err}`)
+    },
+  },
+  setup (options, nuxt) {
+    // Programmatically hook to the `pages:extend` hook
+    nuxt.hook('pages:extend', (pages) => {
+      console.info(`Discovered ${pages.length} pages`)
+    })
+  },
+})
+```
+
+:read-more{to="/docs/4.x/api/advanced/hooks"}
+
+::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/nuxt-lifecycle-hooks?friend=nuxt" target="_blank"}
+Watch Vue School video about using Nuxt lifecycle hooks in modules.
+::
+
+::note
+**Module cleanup**
+:br
+:br
+If your module opens, handles, or starts a watcher, you should close it when the Nuxt lifecycle is done. The `close` hook is available for this.
+
+```ts
+import { defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    nuxt.hook('close', async (nuxt) => {
+      // Your custom code here
+    })
+  },
+})
+```
+::
+
+### Create Custom Hooks
+
+Modules can also define and call their own hooks, which is a powerful pattern for making your module extensible.
+
+If you expect other modules to be able to subscribe to your module's hooks, you should call them in the `modules:done` hook. This ensures that all other modules have had a chance to be set up and register their listeners to your hook during their own `setup` function.
+
+```ts
+// my-module/module.ts
+import { defineNuxtModule } from '@nuxt/kit'
+
+export interface ModuleHooks {
+  'my-module:custom-hook': (payload: { foo: string }) => void
+}
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    // Call your hook in `modules:done`
+    nuxt.hook('modules:done', async () => {
+      const payload = { foo: 'bar' }
+      await nuxt.callHook('my-module:custom-hook', payload)
+    })
+  },
+})
+```
+
+## Add Virtual Files
+
+If you need to add a virtual file that can be imported into the user's app, you can use the `addTemplate` utility.
+
+```ts
+import { addTemplate, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    // The file is added to Nuxt's internal virtual file system and can be imported from '#build/my-module-feature.mjs'
+    addTemplate({
+      filename: 'my-module-feature.mjs',
+      getContents: () => 'export const myModuleFeature = () => "hello world !"',
+    })
+  },
+})
+```
+
+For the server, you should use the `addServerTemplate` utility instead.
+
+```ts
+import { addServerTemplate, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    // The file is added to Nitro's virtual file system and can be imported in the server code from 'my-server-module.mjs'
+    addServerTemplate({
+      filename: 'my-server-module.mjs',
+      getContents: () => 'export const myServerModule = () => "hello world !"',
+    })
+  },
+})
+```
+
+## Update Virtual Files
+
+If you need to update your templates/virtual files, you can leverage the `updateTemplates` utility like this:
+
+```ts
+nuxt.hook('builder:watch', (event, path) => {
+  if (path.includes('my-module-feature.config')) {
+    // This will reload the template that you registered
+    updateTemplates({ filter: t => t.filename === 'my-module-feature.mjs' })
+  }
+})
+```
+
+## Add Type Declarations
+
+You might also want to add a type declaration to the user's project (for example, to augment a Nuxt interface
+or provide a global type of your own). For this, Nuxt provides the `addTypeTemplate` utility that both
+writes a template to the disk and adds a reference to it in the generated `nuxt.d.ts` file.
+
+If your module should augment types handled by Nuxt, you can use `addTypeTemplate` to perform this operation:
+
+```js
+import { addTemplate, addTypeTemplate, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    addTypeTemplate({
+      filename: 'types/my-module.d.ts',
+      getContents: () => `// Generated by my-module
+        interface MyModuleNitroRules {
+          myModule?: { foo: 'bar' }
+        }
+        declare module 'nitropack/types' {
+          interface NitroRouteRules extends MyModuleNitroRules {}
+          interface NitroRouteConfig extends MyModuleNitroRules {}
+        }
+        export {}`,
+    })
+  },
+})
+```
+
+If you need more granular control, you can use the `prepare:types` hook to register a callback that will inject your types.
+
+```ts
+const template = addTemplate({ /* template options */ })
+nuxt.hook('prepare:types', ({ references }) => {
+  references.push({ path: template.dst })
+})
+```
+
+## Extend TypeScript Config
+
+There are multiple ways to extend the TypeScript configuration of the user's project from your module.
+
+The simplest way is to modify the Nuxt configuration directly like this:
+
+<!-- @case-police-ignore tsConfig -->
+```ts
+// extend tsconfig.app.json
+nuxt.options.typescript.tsConfig.include ??= []
+nuxt.options.typescript.tsConfig.include.push(resolve('./augments.d.ts'))
+
+// extend tsconfig.shared.json
+nuxt.options.typescript.sharedTsConfig.include ??= []
+nuxt.options.typescript.sharedTsConfig.include.push(resolve('./augments.d.ts'))
+
+// extend tsconfig.node.json
+nuxt.options.typescript.nodeTsConfig.include ??= []
+nuxt.options.typescript.nodeTsConfig.include.push(resolve('./augments.d.ts'))
+
+// extend tsconfig.server.json
+nuxt.options.nitro.typescript ??= {}
+nuxt.options.nitro.typescript.tsConfig ??= {}
+nuxt.options.nitro.typescript.tsConfig.include ??= []
+nuxt.options.nitro.typescript.tsConfig.include.push(resolve('./augments.d.ts'))
+```
+
+Alternatively, you can use the `prepare:types` and `nitro:prepare:types` hooks to extend the TypeScript references for specific type contexts, or modify the TypeScript configuration similar to the example above.
+
+```ts
+nuxt.hook('prepare:types', ({ references, sharedReferences, nodeReferences }) => {
+  // extend app context
+  references.push({ path: resolve('./augments.d.ts') })
+  // extend shared context
+  sharedReferences.push({ path: resolve('./augments.d.ts') })
+  // extend node context
+  nodeReferences.push({ path: resolve('./augments.d.ts') })
+})
+
+nuxt.hook('nitro:prepare:types', ({ references }) => {
+  // extend server context
+  references.push({ path: resolve('./augments.d.ts') })
+})
+```
+
+::note
+TypeScript references add files to the type context [without being affected by the `exclude` option in `tsconfig.json`](https://www.typescriptlang.org/tsconfig/#exclude).
+::
+
+## Augment Types
+
+Nuxt automatically includes your module's directories in the appropriate type contexts. To augment types from your module, all you need to do is place the type declaration file in the appropriate directory based on the augmented type context. Alternatively, you can [extend the TypeScript configuration](#extend-typescript-config) to augment from an arbitrary location.
+
+- `my-module/runtime/` - app type context (except for the `runtime/server` directory)
+- `my-module/runtime/server/` - server type context
+- `my-module/` - node type context (except for the `runtime/` and `runtime/server` directories)
+
+```bash [Directory Structure]
+-| my-module/   # node type context
+---| runtime/   # app type context
+------| augments.app.d.ts
+------| server/ # server type context
+---------| augments.server.d.ts
+---| module.ts
+---| augments.node.d.ts
+```

package/3.guide/4.modules/5.testing.md

@@ -0,0 +1,76 @@
+---
+title: "Test Your Module"
+description: "Learn how to test your Nuxt module with unit, integration and E2E tests."
+---
+
+Testing helps ensure your module works as expected given various setups. Find in this section how to perform various kinds of tests against your module.
+
+## Write Unit Tests
+
+::tip
+We're still discussing and exploring how to ease unit and integration testing on Nuxt modules.
+:br :br
+[Check out this RFC to join the conversation](https://github.com/nuxt/nuxt/discussions/18399).
+::
+
+## Write E2E Tests
+
+[Nuxt Test Utils](/docs/4.x/getting-started/testing) is the go-to library to help you test your module in an end-to-end way. Here's the workflow to adopt with it:
+
+1. Create a Nuxt application to be used as a "fixture" inside `test/fixtures/*`
+2. Setup Nuxt with this fixture inside your test file
+3. Interact with the fixture using utilities from `@nuxt/test-utils` (e.g. fetching a page)
+4. Perform checks related to this fixture (e.g. "HTML contains ...")
+5. Repeat
+
+In practice, the fixture:
+
+```ts [test/fixtures/ssr/nuxt.config.ts]
+// 1. Create a Nuxt application to be used as a "fixture"
+import MyModule from '../../../src/module'
+
+export default defineNuxtConfig({
+  ssr: true,
+  modules: [
+    MyModule,
+  ],
+})
+```
+
+And its test:
+
+```ts [test/rendering.ts]
+import { describe, expect, it } from 'vitest'
+import { fileURLToPath } from 'node:url'
+import { $fetch, setup } from '@nuxt/test-utils/e2e'
+
+describe('ssr', async () => {
+  // 2. Setup Nuxt with this fixture inside your test file
+  await setup({
+    rootDir: fileURLToPath(new URL('./fixtures/ssr', import.meta.url)),
+  })
+
+  it('renders the index page', async () => {
+    // 3. Interact with the fixture using utilities from `@nuxt/test-utils`
+    const html = await $fetch('/')
+
+    // 4. Perform checks related to this fixture
+    expect(html).toContain('<div>ssr</div>')
+  })
+})
+
+// 5. Repeat
+describe('csr', async () => { /* ... */ })
+```
+
+::tip
+An example of such a workflow is available on [the module starter](https://github.com/nuxt/starter/blob/module/test/basic.test.ts).
+::
+
+## Test Manually
+
+Having a playground Nuxt application to test your module when developing it is really useful. [The module starter integrates one for that purpose](/docs/4.x/guide/modules/getting-started#develop-your-module).
+
+You can test your module with other Nuxt applications (applications that are not part of your module repository) locally. To do so, you can use [`npm pack`](https://docs.npmjs.com/cli/commands/npm-pack/) command, or your package manager equivalent, to create a tarball from your module. Then in your test project, you can add your module to `package.json` packages as: `"my-module": "file:/path/to/tarball.tgz"`.
+
+After that, you should be able to reference `my-module` like in any regular project.

package/3.guide/4.modules/6.best-practices.md

@@ -0,0 +1,104 @@
+---
+title: "Follow Best Practices"
+description: "Build performant and maintainable Nuxt modules with these guidelines."
+---
+
+With great power comes great responsibility. While modules are powerful, here are some best practices to keep in mind while authoring modules to keep applications performant and developer experience great.
+
+## Handle Async Setup
+
+As we've seen, Nuxt modules can be asynchronous. For example, you may want to develop a module that needs fetching some API or calling an async function.
+
+However, be careful with asynchronous behaviors as Nuxt will wait for your module to setup before going to the next module and starting the development server, build process, etc. Prefer deferring time-consuming logic to Nuxt hooks.
+
+::warning
+If your module takes more than **1 second** to setup, Nuxt will emit a warning about it.
+::
+
+## Prefix Your Exports
+
+Nuxt modules should provide an explicit prefix for any exposed configuration, plugin, API, composable, component, or server route to avoid conflicts with other modules, Nuxt internals, or user-defined code.
+
+Ideally, prefix them with your module's name. For example, if your module is called `nuxt-foo`:
+
+| Type | ❌ Avoid | ✅ Prefer |
+| --- | --- | --- |
+| Components | `<Button>`, `<Modal>` | `<FooButton>`, `<FooModal>` |
+| Composables | `useData()`, `useModal()` | `useFooData()`, `useFooModal()` |
+| Server routes | `/api/track`, `/api/data` | `/api/_foo/track`, `/api/_foo/data` |
+
+### Server Routes
+
+This is particularly important for server routes, where common paths like `/api/auth`, `/api/login`, or `/api/user` are very likely already used by the application.
+
+Use a unique prefix based on your module name:
+- `/api/_foo/...` (using underscore prefix)
+- `/_foo/...` (for non-API routes)
+
+## Use Lifecycle Hooks
+
+When your module needs to perform one-time setup tasks (like generating configuration files, setting up databases, or installing dependencies), use lifecycle hooks instead of running the logic in your main `setup` function.
+
+```ts
+import { addServerHandler, defineNuxtModule } from 'nuxt/kit'
+import semver from 'semver'
+
+export default defineNuxtModule({
+  meta: {
+    name: 'my-database-module',
+    version: '1.0.0',
+  },
+  async onInstall (nuxt) {
+    // One-time setup: create database schema, generate config files, etc.
+    await generateDatabaseConfig(nuxt.options.rootDir)
+  },
+  async onUpgrade (options, nuxt, previousVersion) {
+    // Handle version-specific migrations
+    if (semver.lt(previousVersion, '1.0.0')) {
+      await migrateLegacyData()
+    }
+  },
+  setup (options, nuxt) {
+    // Regular setup logic that runs on every build
+    addServerHandler({ /* ... */ })
+  },
+})
+```
+
+This pattern prevents unnecessary work on every build and provides a better developer experience. See the [lifecycle hooks documentation](/docs/4.x/api/kit/modules#using-lifecycle-hooks-for-module-installation-and-upgrade) for more details.
+
+## Be TypeScript Friendly
+
+Nuxt has first-class TypeScript integration for the best developer experience.
+
+Exposing types and using TypeScript to develop modules benefits users even when not using TypeScript directly.
+
+## Use ESM Syntax
+
+Nuxt relies on native ESM. Please read [Native ES Modules](/docs/4.x/guide/concepts/esm) for more information.
+
+## Document Your Module
+
+Consider documenting module usage in the readme file:
+
+- Why use this module?
+- How to use this module?
+- What does this module do?
+
+Linking to the integration website and documentation is always a good idea.
+
+## Provide a Demo
+
+It's a good practice to make a minimal reproduction with your module and [StackBlitz](https://nuxt.new/s/v4) that you add to your module readme.
+
+This not only provides potential users of your module a quick and easy way to experiment with the module but also an easy way for them to build minimal reproductions they can send you when they encounter issues.
+
+## Stay Version Agnostic
+
+Nuxt, Nuxt Kit, and other new toolings are made to have both forward and backward compatibility in mind.
+
+Please use "X for Nuxt" instead of "X for Nuxt 3" to avoid fragmentation in the ecosystem and prefer using `meta.compatibility` to set Nuxt version constraints.
+
+## Follow Starter Conventions
+
+The module starter comes with a default set of tools and configurations (e.g. ESLint configuration). If you plan on open-sourcing your module, sticking with those defaults ensures your module shares a consistent coding style with other [community modules](/modules) out there, making it easier for others to contribute.

package/3.guide/4.modules/7.ecosystem.md

@@ -0,0 +1,32 @@
+---
+title: "Publish & Share Your Module"
+description: "Join the Nuxt module ecosystem and publish your module to npm."
+---
+
+The [Nuxt module ecosystem](/modules) represents more than 35 million monthly NPM downloads and provides extended functionalities and integrations with all sort of tools. You can be part of this ecosystem!
+
+::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/exploring-nuxt-modules-ecosystem-and-module-types?friend=nuxt" target="_blank"}
+Watch Vue School video about Nuxt module types.
+::
+
+## Understand Module Types
+
+**Official modules** are modules prefixed (scoped) with `@nuxt/` (e.g. [`@nuxt/content`](https://content.nuxt.com)). They are made and maintained actively by the Nuxt team. Like with the framework, contributions from the community are more than welcome to help make them better!
+
+**Community modules** are modules prefixed (scoped) with `@nuxtjs/` (e.g. [`@nuxtjs/tailwindcss`](https://tailwindcss.nuxtjs.org)). They are proven modules made and maintained by community members. Again, contributions are welcome from anyone.
+
+**Third-party and other community modules** are modules (often) prefixed with `nuxt-`. Anyone can make them, using this prefix allows these modules to be discoverable on npm. This is the best starting point to draft and try an idea!
+
+**Private or personal modules** are modules made for your own use case or company. They don't need to follow any naming rules to work with Nuxt and are often seen scoped under an npm organization (e.g. `@my-company/nuxt-auth`)
+
+## List Your Module
+
+Any community modules are welcome to be listed on [the module list](/modules). To be listed, [open an issue in the nuxt/modules](https://github.com/nuxt/modules/issues/new?template=module_request.yml) repository. The Nuxt team can help you to apply best practices before listing.
+
+## Join nuxt-modules
+
+By moving your modules to [nuxt-modules](https://github.com/nuxt-modules), there is always someone else to help, and this way, we can join forces to make one perfect solution.
+
+If you have an already published and working module, and want to transfer it to `nuxt-modules`, [open an issue in nuxt/modules](https://github.com/nuxt/modules/issues/new).
+
+By joining `nuxt-modules` we can rename your community module under the `@nuxtjs/` scope and provide a subdomain (e.g. `my-module.nuxtjs.org`) for its documentation.

package/3.guide/4.modules/index.md

@@ -0,0 +1,36 @@
+---
+title: 'Module Author Guide'
+titleTemplate: '%s'
+description: 'Learn how to create a Nuxt module to integrate, enhance or extend any Nuxt applications.'
+navigation: false
+surround: false
+---
+
+Nuxt's [configuration](/docs/4.x/api/nuxt-config) and [hooks](/docs/4.x/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 `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.
+
+::card-group{class="sm:grid-cols-1"}
+  ::card{icon="i-lucide-rocket" title="Create Your First Module" to="/docs/4.x/guide/modules/getting-started"}
+  Learn how to create your first Nuxt module using the official starter template.
+  ::
+  ::card{icon="i-lucide-box" title="Understand Module Structure" to="/docs/4.x/guide/modules/module-anatomy"}
+  Learn how Nuxt modules are structured and how to define them.
+  ::
+  ::card{icon="i-lucide-code" title="Add Plugins, Components & More" to="/docs/4.x/guide/modules/recipes-basics"}
+  Learn how to inject plugins, components, composables and server routes from your module.
+  ::
+  ::card{icon="i-lucide-layers" title="Use Hooks & Extend Types" to="/docs/4.x/guide/modules/recipes-advanced"}
+  Master lifecycle hooks, virtual files and TypeScript declarations in your modules.
+  ::
+  ::card{icon="i-lucide-test-tube" title="Test Your Module" to="/docs/4.x/guide/modules/testing"}
+  Learn how to test your Nuxt module with unit, integration and E2E tests.
+  ::
+  ::card{icon="i-lucide-medal" title="Follow Best Practices" to="/docs/4.x/guide/modules/best-practices"}
+  Build performant and maintainable Nuxt modules with these guidelines.
+  ::
+  ::card{icon="i-lucide-globe" title="Publish & Share Your Module" to="/docs/4.x/guide/modules/ecosystem"}
+  Join the Nuxt module ecosystem and publish your module to npm.
+  ::
+::

package/3.guide/{5.going-further → 6.going-further}/1.internals.md

@@ -16,7 +16,7 @@ allowing different components to communicate with each other. You can think of i
 This context is globally available to be used with [Nuxt Kit](/docs/4.x/guide/going-further/kit) composables.
 Therefore only one instance of Nuxt is allowed to run per process.
 
-To extend the Nuxt interface and hook into different stages of the build process, we can use [Nuxt Modules](/docs/4.x/guide/going-further/modules).
+To extend the Nuxt interface and hook into different stages of the build process, we can use [Nuxt modules](/docs/4.x/guide/modules).
 
 For more details, check out [the source code](https://github.com/nuxt/nuxt/blob/main/packages/nuxt/src/core/nuxt.ts).
 
@@ -77,6 +77,6 @@ Nuxt builds and bundles project using Node.js but also has a runtime side.
 
 While both areas can be extended, that runtime context is isolated from build-time. Therefore, they are not supposed to share state, code, or context other than runtime configuration!
 
-`nuxt.config` and [Nuxt Modules](/docs/4.x/guide/going-further/modules) can be used to extend the build context, and [Nuxt Plugins](/docs/4.x/directory-structure/app/plugins) can be used to extend runtime.
+`nuxt.config` and [Nuxt modules](/docs/4.x/guide/modules) can be used to extend the build context, and [Nuxt Plugins](/docs/4.x/directory-structure/app/plugins) can be used to extend runtime.
 
-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/4.x/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/4.x/guide/modules).

package/3.guide/{5.going-further → 6.going-further}/2.hooks.md

@@ -9,7 +9,7 @@ The hooking system is powered by [unjs/hookable](https://github.com/unjs/hookabl
 
 ## Nuxt Hooks (Build Time)
 
-These hooks are available for [Nuxt Modules](/docs/4.x/guide/going-further/modules) and build context.
+These hooks are available for [Nuxt modules](/docs/4.x/guide/modules) and build context.
 
 ### Within `nuxt.config.ts`
 

package/3.guide/{5.going-further → 6.going-further}/4.kit.md

@@ -3,7 +3,7 @@ title: "Nuxt Kit"
 description: "@nuxt/kit provides features for module authors."
 ---
 
-Nuxt Kit provides composable utilities to make interacting with [Nuxt Hooks](/docs/4.x/api/advanced/hooks), the [Nuxt Interface](/docs/4.x/guide/going-further/internals#the-nuxt-interface) and developing [Nuxt Modules](/docs/4.x/guide/going-further/modules) super easy.
+Nuxt Kit provides composable utilities to make interacting with [Nuxt Hooks](/docs/4.x/api/advanced/hooks), the [Nuxt Interface](/docs/4.x/guide/going-further/internals#the-nuxt-interface) and developing [Nuxt modules](/docs/4.x/guide/modules) super easy.
 
 ::read-more{to="/docs/4.x/api/kit"}
 Discover all Nuxt Kit utilities.

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

@@ -38,7 +38,7 @@ The properties of `useHead` can be dynamic, accepting `ref`, `computed` and `rea
 ## Type
 
 ```ts [Signature]
-export function useHead (meta: MaybeComputedRef<MetaObject>): void
+export function useHead (meta: MaybeComputedRef<MetaObject>): ActiveHeadEntry<UseHeadInput>
 
 interface MetaObject {
   title?: string
@@ -52,6 +52,21 @@ interface MetaObject {
   htmlAttrs?: HtmlAttributes
   bodyAttrs?: BodyAttributes
 }
+
+interface ActiveHeadEntry<Input> {
+  /**
+   * Updates the entry with new input.
+   *
+   * Will first clear any side effects for previous input.
+   */
+  patch: (input: Input) => void
+  /**
+   * Dispose the entry, removing it from the active head.
+   *
+   * Will queue side effects for removal.
+   */
+  dispose: () => void
+}
 ```
 
 See [@unhead/schema](https://github.com/unjs/unhead/blob/main/packages/vue/src/types/schema.ts) for more detailed types.

package/4.api/4.commands/add.md

@@ -23,7 +23,7 @@ npx nuxt add <TEMPLATE> <NAME> [--cwd=<directory>] [--logLevel=<silent|info|verb
 | `NAME`     | Specify name of the generated file                                                                                                                                                                               |
 <!--/add-args-->
 
-### Options
+## Options
 
 <!--add-opts-->
 | Option                               | Default | Description                              |

package/5.community/4.contribution.md

@@ -11,7 +11,7 @@ There is a range of different ways you might be able to contribute to the Nuxt e
 The Nuxt ecosystem includes many different projects and organizations:
 
 * [nuxt/](https://github.com/nuxt) - core repositories for the Nuxt framework itself. [**nuxt/nuxt**](https://github.com/nuxt/nuxt) contains the Nuxt framework (both versions 2 and 3).
-* [nuxt-modules/](https://github.com/nuxt-modules) - community-contributed and maintained modules and libraries. There is a [process to migrate a module](/docs/4.x/guide/going-further/modules/#joining-nuxt-modules-and-nuxtjs) to `nuxt-modules`. While these modules have individual maintainers, they are not dependent on a single person.
+* [nuxt-modules/](https://github.com/nuxt-modules) - community-contributed and maintained modules and libraries. There is a [process to migrate a module](/docs/4.x/guide/modules/ecosystem) to `nuxt-modules`. While these modules have individual maintainers, they are not dependent on a single person.
 * [unjs/](https://github.com/unjs) - many of these libraries are used throughout the Nuxt ecosystem. They are designed to be universal libraries that are framework- and environment-agnostic. We welcome contributions and usage by other frameworks and projects.
 
 ## How To Contribute
@@ -100,7 +100,7 @@ Our aim is ensuring quality and maintaining the joy of collaborating and communi
 
 ### Create a Module
 
-If you've built something with Nuxt that's cool, why not [extract it into a module](/docs/4.x/guide/going-further/modules), so it can be shared with others? We have [many excellent modules already](/modules), but there's always room for more.
+If you've built something with Nuxt that's cool, why not [extract it into a module](/docs/4.x/guide/modules), so it can be shared with others? We have [many excellent modules already](/modules), but there's always room for more.
 
 If you need help while building it, feel free to [check in with us](/docs/4.x/community/getting-help).
 
@@ -126,7 +126,7 @@ The following conventions are _required_ within the `nuxt/` organization and rec
 
 #### Module Conventions
 
-Modules should follow the [Nuxt module template](https://github.com/nuxt/starter/tree/module). See [module guide](/docs/4.x/guide/going-further/modules) for more information.
+Modules should follow the [Nuxt module template](https://github.com/nuxt/starter/tree/module). See [module guide](/docs/4.x/guide/modules) for more information.
 
 #### Use Core `unjs/` Libraries
 

package/5.community/5.framework-contribution.md

@@ -8,7 +8,7 @@ Once you've read the [general contribution guide](/docs/4.x/community/contributi
 
 ## Monorepo Guide
 
-- `packages/kit`: Toolkit for authoring Nuxt Modules, published as [`@nuxt/kit`](https://www.npmjs.com/package/@nuxt/kit).
+- `packages/kit`: Toolkit for authoring Nuxt modules, published as [`@nuxt/kit`](https://www.npmjs.com/package/@nuxt/kit).
 - `packages/nuxt`: The core of Nuxt, published as [`nuxt`](https://www.npmjs.com/package/nuxt).
 - `packages/schema`: Cross-version Nuxt typedefs and defaults, published as [`@nuxt/schema`](https://www.npmjs.com/package/@nuxt/schema).
 - `packages/rspack`: The [Rspack](https://rspack.rs) bundler for Nuxt, published as [`@nuxt/rspack-builder`](https://www.npmjs.com/package/@nuxt/rspack-builder).

package/7.migration/2.configuration.md

@@ -115,7 +115,7 @@ Nuxt has built-in support for loading `.env` files. Avoid directly importing it
 
 ## Modules
 
-Nuxt and Nuxt Modules are now build-time-only.
+Nuxt and Nuxt modules are now build-time-only.
 
 ### Migration
 
@@ -133,7 +133,7 @@ Nuxt and Nuxt Modules are now build-time-only.
 ```
 
 ::tip
-If you are a module author, you can check out [more information about module compatibility](/docs/4.x/migration/module-authors) and [our module author guide](/docs/4.x/guide/going-further/modules).
+If you are a module author, you can check out [more information about module compatibility](/docs/4.x/migration/module-authors) and [our module author guide](/docs/4.x/guide/modules).
 ::
 
 ## Directory Changes

package/7.migration/20.module-authors.md

@@ -7,7 +7,7 @@ description: 'Learn how to migrate from Nuxt 2 to Nuxt 3 modules.'
 
 Nuxt 3 has a basic backward compatibility layer for Nuxt 2 modules using `@nuxt/kit` auto wrappers. But there are usually steps to follow to make modules compatible with Nuxt 3 and sometimes, using Nuxt Bridge is required for cross-version compatibility.
 
-We have prepared a [Dedicated Guide](/docs/4.x/guide/going-further/modules) for authoring Nuxt 3 ready modules using `@nuxt/kit`. Currently best migration path is to follow it and rewrite your modules. Rest of this guide includes preparation steps if you prefer to avoid a full rewrite yet making modules compatible with Nuxt 3.
+We have prepared a [Dedicated Guide](/docs/4.x/guide/modules) for authoring Nuxt 3 ready modules using `@nuxt/kit`. Currently best migration path is to follow it and rewrite your modules. Rest of this guide includes preparation steps if you prefer to avoid a full rewrite yet making modules compatible with Nuxt 3.
 
 ::tip{icon="i-lucide-puzzle" to="/modules"}
 Explore Nuxt 3 compatible modules.
@@ -78,7 +78,7 @@ Your module should work even if it's only added to [`buildModules`](/docs/4.x/ap
 (*) Unless it is for `nuxt dev` purpose only and guarded with `if (nuxt.options.dev) { }`.
 
 ::tip
-Continue reading about Nuxt 3 modules in the [Modules Author Guide](/docs/4.x/guide/going-further/modules).
+Continue reading about Nuxt 3 modules in the [Modules Author Guide](/docs/4.x/guide/modules).
 ::
 
 ### Use TypeScript (Optional)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nuxt/docs-nightly",
-  "version": "4.2.3-29422039.47e05245",
+  "version": "4.2.3-29425455.7d502292",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/nuxt/nuxt.git",