@nuxt/docs-nightly 4.2.3-29422039.47e05245 → 4.2.3-29424584.c1b3590f

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

@@ -17,9 +17,7 @@ Or follow the steps below to set up a new Nuxt project on your computer.
 
 ## New Project
 
-<!-- TODO: need to fix upstream in nuxt/nuxt.com -->
-<!-- markdownlint-disable-next-line MD001 -->
-#### Prerequisites
+### Prerequisites
 
 - **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.

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

@@ -517,7 +517,7 @@ Here are a few modules to help you get started:
 - [Nuxt UI](https://ui.nuxt.com): A UI Library for Modern Web Apps
 - [Panda CSS](https://panda-css.com/docs/installation/nuxt): CSS-in-JS engine that generates atomic CSS at build time
 
-Nuxt modules provide you with a good developer experience out of the box, but remember that if your favorite tool doesn't have a module, it doesn't mean that you can't use it with Nuxt! You can configure it yourself for your own project. Depending on the tool, you might need to use a [Nuxt plugin](/docs/4.x/directory-structure/app/plugins) and/or [make your own module](/docs/4.x/guide/going-further/modules). Share them with the [community](/modules) if you do!
+Nuxt modules provide you with a good developer experience out of the box, but remember that if your favorite tool doesn't have a module, it doesn't mean that you can't use it with Nuxt! You can configure it yourself for your own project. Depending on the tool, you might need to use a [Nuxt plugin](/docs/4.x/directory-structure/app/plugins) and/or [make your own module](/docs/4.x/guide/modules). Share them with the [community](/modules) if you do!
 
 ### Easily Load Webfonts
 

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

@@ -5,7 +5,7 @@ navigation.icon: i-lucide-circle-check
 ---
 
 ::tip
-If you are a module author, you can find more specific information in the [Module Author's guide](/docs/4.x/guide/going-further/modules#testing).
+If you are a module author, you can find more specific information in the [Module Author's guide](/docs/4.x/guide/modules/testing).
 ::
 
 Nuxt offers first-class support for end-to-end and unit testing of your Nuxt application via `@nuxt/test-utils`, a library of test utilities and configuration that currently powers the [tests we use on Nuxt itself](https://github.com/nuxt/nuxt/tree/main/test) and tests throughout the module ecosystem.

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

@@ -463,7 +463,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/going-further/modules#custom-hooks) 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/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.
 
 👉 See [PR #31507](https://github.com/nuxt/nuxt/pull/31507) and [issue #25719](https://github.com/nuxt/nuxt/issues/25719) for more details.
 

package/2.directory-structure/1.modules.md

@@ -59,7 +59,7 @@ modules/
   2.second-module.ts
 ```
 
-:read-more{to="/docs/4.x/guide/going-further/modules"}
+:read-more{to="/docs/4.x/guide/modules"}
 
 ::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/creating-your-first-module-from-scratch?friend=nuxt" target="_blank"}
 Watch Vue School video about Nuxt private modules.

package/3.guide/0.index.md

@@ -11,12 +11,18 @@ surround: false
   Discover the main concepts behind Nuxt, from auto-import, hybrid rendering to its TypeScript support.
   ::
   ::card{icon="i-lucide-square-check" title="Best Practices" to="/docs/4.x/guide/best-practices"}
-  Learn about best practices when developing with Nuxt
+  Learn about best practices when developing with Nuxt.
+  ::
+  ::card{icon="i-lucide-bot" title="Working with AI" to="/docs/4.x/guide/ai"}
+  Integrate AI tools into your Nuxt workflow with MCP Server and LLMs.txt.
+  ::
+  ::card{icon="i-lucide-box" title="Module Author Guide" to="/docs/4.x/guide/modules"}
+  Learn how to create Nuxt modules to integrate, enhance or extend any Nuxt application.
   ::
   ::card{icon="i-lucide-book-open" title="Recipes" to="/docs/4.x/guide/recipes"}
   Find solutions to common problems and learn how to implement them in your Nuxt project.
   ::
   ::card{icon="i-lucide-star" title="Going Further" to="/docs/4.x/guide/going-further"}
-  Master Nuxt with advanced concepts like experimental features, hooks, modules, and more.
+  Master Nuxt with advanced concepts like experimental features, hooks, and more.
   ::
 ::

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

@@ -45,4 +45,4 @@ Nuxt modules are now build-time-only, and the `buildModules` property used in Nu
 
 Everyone has the opportunity to develop modules and we cannot wait to see what you will build.
 
-:read-more{to="/docs/4.x/guide/going-further/modules" title="Module Author Guide"}
+:read-more{to="/docs/4.x/guide/modules" title="Module Author Guide"}

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

@@ -52,7 +52,7 @@ Nuxt projects rely on auto-generated types to work properly. These types are sto
 The generated `tsconfig.json` files inside the [`.nuxt`](/docs/4.x/directory-structure/nuxt) directory include **recommended basic TypeScript configuration** for your project, references to [auto-imports](/docs/4.x/guide/concepts/auto-imports), [API route types](/docs/4.x/guide/concepts/server-engine#typed-api-routes), path aliases like `#imports`, `~/file`, or `#build/file`, and more.
 
 ::warning
-Nuxt relies on this configuration, and [Nuxt Modules](/docs/4.x/guide/going-further/modules) can extend it as well. For this reason, it is not recommended to modify your `tsconfig.json` file directly, as doing so could overwrite important settings. Instead, extend it via `nuxt.config.ts`. [Learn more about extending the configuration here](/docs/4.x/directory-structure/tsconfig).
+Nuxt relies on this configuration, and [Nuxt modules](/docs/4.x/guide/modules) can extend it as well. For this reason, it is not recommended to modify your `tsconfig.json` file directly, as doing so could overwrite important settings. Instead, extend it via `nuxt.config.ts`. [Learn more about extending the configuration here](/docs/4.x/directory-structure/tsconfig).
 ::
 
 ::tip{icon="i-lucide-video" to="https://youtu.be/umLI7SlPygY" target="_blank"}
@@ -95,7 +95,7 @@ Similarly:
 - For the `server` context, place the augmentation file in the `server/` directory.
 - For types that are **shared between the app and server**, place the file in the `shared/` directory.
 
-::read-more{to="/docs/4.x/guide/going-further/modules#extending-tsconfigjson"}
+::read-more{to="/docs/4.x/guide/modules/recipes-advanced#extend-typescript-config"}
 Read more about augmenting specific type contexts from **files outside those contexts** in the Module Author Guide.
 ::
 

package/3.guide/4.modules/.navigation.yml

@@ -0,0 +1,3 @@
+title: Module Author Guide
+titleTemplate: '%s · Nuxt Modules Author Guide'
+icon: i-lucide-box

package/3.guide/4.modules/1.getting-started.md

@@ -0,0 +1,103 @@
+---
+title: "Create Your First Module"
+description: "Learn how to create your first Nuxt module using the official starter template."
+---
+
+## Create a Module
+
+We recommend you get started with Nuxt modules using our [starter template](https://github.com/nuxt/starter/tree/module):
+
+::code-group{sync="pm"}
+
+```bash [npm]
+npm create nuxt -- -t module my-module
+```
+
+```bash [yarn]
+yarn create nuxt -t module my-module
+```
+
+```bash [pnpm]
+pnpm create nuxt -t module my-module
+```
+
+```bash [bun]
+bun create nuxt --template=module my-module
+```
+::
+
+This will create a `my-module` project with all the boilerplate necessary to develop and publish your module.
+
+**Next steps:**
+
+1. Open `my-module` in your IDE of choice
+2. Install dependencies using your favorite package manager
+3. Prepare local files for development using `npm run dev:prepare`
+4. Follow this document to learn more about Nuxt modules
+
+## Use the Starter Template
+
+Learn how to perform basic tasks with the module starter.
+
+::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/navigating-the-official-starter-template?friend=nuxt" target="_blank"}
+Watch Vue School video about Nuxt module starter template.
+::
+
+### Develop Your Module
+
+While your module source code lives inside the `src` directory, to develop a module you often need a Nuxt application to test it against. That's what the `playground` directory is for. It's a Nuxt application you can tinker with that is already configured to run with your module.
+
+You can interact with the playground like with any Nuxt application.
+
+- Launch its development server with `npm run dev`, it should reload itself as you make changes to your module in the `src` directory
+- Build it with `npm run dev:build`
+
+::note
+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.
+::
+
+### Run Tests
+
+The module starter comes with a basic test suite:
+
+- A linter powered by [ESLint](https://eslint.org), run it with `npm run lint`
+- A test runner powered by [Vitest](https://vitest.dev), run it with `npm run test` or `npm run test:watch`
+
+::tip
+Feel free to augment this default test strategy to better suit your needs.
+::
+
+### Build Your Module
+
+Nuxt modules come with their own builder provided by [`@nuxt/module-builder`](https://github.com/nuxt/module-builder#readme). This builder doesn't require any configuration on your end, supports TypeScript, and makes sure your assets are properly bundled to be distributed to other Nuxt applications.
+
+You can build your module by running `npm run prepack`.
+
+::tip
+While building your module can be useful in some cases, most of the time you won't need to build it on your own: the `playground` takes care of it while developing, and the release script also has you covered when publishing.
+::
+
+### Publish to npm
+
+::important
+Before publishing your module to npm, makes sure you have an [npmjs.com](https://www.npmjs.com) account and that you're authenticated to it locally with `npm login`.
+::
+
+While you can publish your module by bumping its version and using the `npm publish` command, the module starter comes with a release script that helps you make sure you publish a working version of your module to npm and more.
+
+To use the release script, first, commit all your changes (we recommend you follow [Conventional Commits](https://www.conventionalcommits.org) to also take advantage of automatic version bump and changelog update), then run the release script with `npm run release`.
+
+When running the release script, the following will happen:
+
+- First, it will run your test suite by:
+  - Running the linter (`npm run lint`)
+  - Running unit, integration, and e2e tests (`npm run test`)
+  - Building the module (`npm run prepack`)
+- Then, if your test suite went well, it will proceed to publish your module by:
+  - Bumping your module version and generating a changelog according to your Conventional Commits
+  - Publishing the module to npm (for that purpose, the module will be built again to ensure its updated version number is taken into account in the published artifact)
+  - Pushing a git tag representing the newly published version to your git remote origin
+
+::tip
+As with other scripts, feel free to fine-tune the default `release` script in your `package.json` to better suit your needs.
+::

package/3.guide/4.modules/2.module-anatomy.md

@@ -0,0 +1,138 @@
+---
+title: "Understand Module Structure"
+description: "Learn how Nuxt modules are structured and how to define them."
+---
+
+There are two types of Nuxt modules:
+
+- published modules are distributed on npm - you can see a list of some community modules on [the Nuxt website](/modules).
+- "local" modules exist within a Nuxt project, either [inlined in Nuxt config](/docs/4.x/api/nuxt-config#modules) or within [the `modules` directory](/docs/4.x/directory-structure/modules).
+
+In either case, they work in the same way.
+
+## Define Your Module
+
+::note
+When using the starter, your module definition is available at `src/module.ts`.
+::
+
+The module definition is the entry point of your module. It's what gets loaded by Nuxt when your module is referenced within a Nuxt configuration.
+
+At a low level, a Nuxt module definition is a simple, potentially asynchronous, function accepting inline user options and a `nuxt` object to interact with Nuxt.
+
+```ts
+export default function (inlineOptions, nuxt) {
+  // You can do whatever you like here..
+  console.log(inlineOptions.token) // `123`
+  console.log(nuxt.options.dev) // `true` or `false`
+  nuxt.hook('ready', (nuxt) => {
+    console.log('Nuxt is ready')
+  })
+}
+```
+
+You can get type hinting for this function using the higher-level `defineNuxtModule` helper provided by [Nuxt Kit](/docs/4.x/guide/going-further/kit).
+
+```ts
+import { defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule((options, nuxt) => {
+  nuxt.hook('pages:extend', (pages) => {
+    console.log(`Discovered ${pages.length} pages`)
+  })
+})
+```
+
+However, **we do not recommend** using this low-level function definition. Instead, to define a module, **we recommend** using the object-syntax with `meta` property to identify your module, especially when publishing to npm.
+
+This helper makes writing Nuxt modules more straightforward by implementing many common patterns needed by modules, guaranteeing future compatibility and improving the experience for both module authors and users.
+
+```ts
+import { defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  meta: {
+    // Usually the npm package name of your module
+    name: '@nuxtjs/example',
+    // The key in `nuxt.config` that holds your module options
+    configKey: 'sample',
+    // Compatibility constraints
+    compatibility: {
+      // Semver version of supported nuxt versions
+      nuxt: '>=3.0.0',
+    },
+  },
+  // Default configuration options for your module, can also be a function returning those
+  defaults: {},
+  // Shorthand sugar to register Nuxt hooks
+  hooks: {},
+  // Configuration for other modules - this does not ensure the module runs before
+  // your module, but it allows you to change the other module's configuration before it runs
+  moduleDependencies: {
+    'some-module': {
+      // You can specify a version constraint for the module. If the user has a different
+      // version installed, Nuxt will throw an error on startup.
+      version: '>=2',
+      // By default moduleDependencies will be added to the list of modules to be installed
+      // by Nuxt unless `optional` is set.
+      optional: true,
+      // Any configuration that should override `nuxt.options`.
+      overrides: {},
+      // Any configuration that should be set. It will override module defaults but
+      // will not override any configuration set in `nuxt.options`.
+      defaults: {},
+    },
+  },
+  // The function holding your module logic, it can be asynchronous
+  setup (moduleOptions, nuxt) {
+    // ...
+  },
+})
+```
+
+`defineNuxtModule` returns a wrapper function with the lower level `(inlineOptions, nuxt)` module signature. This wrapper function applies defaults and other necessary steps before calling your `setup` function:
+
+- Support `defaults` and `meta.configKey` for automatically merging module options
+- Type hints and automated type inference
+- Ensure module gets installed only once using a unique key computed from `meta.name` or `meta.configKey`
+- Automatically register Nuxt hooks
+- Automatically check for compatibility issues based on module meta
+- Expose `getOptions` and `getMeta` for internal usage of Nuxt
+- Ensuring backward and upward compatibility as long as the module is using `defineNuxtModule` from the latest version of `@nuxt/kit`
+- Integration with module builder tooling
+
+## Add Runtime Code
+
+::note
+When using the starter, the runtime directory is `src/runtime/`.
+::
+
+Modules, like everything in a Nuxt configuration, aren't included in your application runtime. However, you might want your module to provide, or inject runtime code to the application it's installed on. That's what the runtime directory enables you to do.
+
+Inside the runtime directory, you can provide any kind of assets related to the Nuxt app:
+- Vue components
+- Composables
+- [Nuxt plugins](/docs/4.x/directory-structure/app/plugins)
+
+To the [server engine](/docs/4.x/guide/concepts/server-engine), Nitro:
+- API routes
+- Middlewares
+- Nitro plugins
+
+Or any other kind of asset you want to inject in users' Nuxt applications:
+- Stylesheets
+- 3D models
+- Images
+- etc.
+
+You'll then be able to inject all those assets inside the application from your [module definition](#define-your-module).
+
+::tip
+Learn more about asset injection in [the recipes section](/docs/4.x/guide/modules/recipes-basics).
+::
+
+::warning
+Published modules cannot leverage auto-imports for assets within their runtime directory. Instead, they have to import them explicitly from `#imports` or alike.
+:br :br
+Auto-imports are not enabled for files within `node_modules` (the location where a published module will eventually live) for performance reasons.
+::

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

@@ -0,0 +1,299 @@
+---
+title: "Add Plugins, Components & More"
+description: "Learn how to inject plugins, components, composables and server routes from your module."
+---
+
+Here are some common patterns used by module authors.
+
+## Modify Nuxt Configuration
+
+Nuxt configuration can be read and altered by modules. Here's an example of a module enabling an experimental feature.
+
+```js
+import { defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    // We create the `experimental` object if it doesn't exist yet
+    nuxt.options.experimental ||= {}
+    nuxt.options.experimental.componentIslands = true
+  },
+})
+```
+
+When you need to handle more complex configuration alterations, you should consider using [defu](https://github.com/unjs/defu).
+
+::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/extending-and-altering-nuxt-configuration-and-options?friend=nuxt" target="_blank"}
+Watch Vue School video about altering Nuxt configuration.
+::
+
+## Expose Options to Runtime
+
+Because modules aren't part of the application runtime, their options aren't either. However, in many cases, you might need access to some of these module options within your runtime code. We recommend exposing the needed config using Nuxt's [`runtimeConfig`](/docs/4.x/api/nuxt-config#runtimeconfig).
+
+<!-- TODO: Update after #18466 (or equivalent) -->
+
+```js
+import { defineNuxtModule } from '@nuxt/kit'
+import { defu } from 'defu'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    nuxt.options.runtimeConfig.public.myModule = defu(nuxt.options.runtimeConfig.public.myModule, {
+      foo: options.foo,
+    })
+  },
+})
+```
+
+Note that we use [`defu`](https://github.com/unjs/defu) to extend the public runtime configuration the user provides instead of overwriting it.
+
+You can then access your module options in a plugin, component, the application like any other runtime configuration:
+
+```js
+import { useRuntimeConfig } from '@nuxt/kit'
+
+const options = useRuntimeConfig().public.myModule
+```
+
+::warning
+Be careful not to expose any sensitive module configuration on the public runtime config, such as private API keys, as they will end up in the public bundle.
+::
+
+:read-more{to="/docs/4.x/guide/going-further/runtime-config"}
+
+::tip{icon="i-lucide-video" to="https://vueschool.io/lessons/passing-and-exposing-module-options?friend=nuxt" target="_blank"}
+Watch Vue School video about passing and exposing Nuxt module options.
+::
+
+## Add Plugins
+
+Plugins are a common way for a module to add runtime logic. You can use the `addPlugin` utility to register them from your module.
+
+```js
+import { addPlugin, createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    // Create resolver to resolve relative paths
+    const resolver = createResolver(import.meta.url)
+
+    addPlugin(resolver.resolve('./runtime/plugin'))
+  },
+})
+```
+
+:read-more{to="/docs/4.x/guide/going-further/kit"}
+
+## Add Components
+
+If your module should provide Vue components, you can use the `addComponent` utility to add them as auto-imports for Nuxt to resolve.
+
+```ts twoslash
+import { addComponent, createResolver, defineNuxtModule, useRuntimeConfig } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    // From the runtime directory
+    addComponent({
+      name: 'MySuperComponent', // name of the component to be used in vue templates
+      export: 'MySuperComponent', // (optional) if the component is a named (rather than default) export
+      filePath: resolver.resolve('runtime/components/MySuperComponent.vue'),
+    })
+
+    // From a library
+    addComponent({
+      name: 'MyAwesomeComponent', // name of the component to be used in vue templates
+      export: 'MyAwesomeComponent', // (optional) if the component is a named (rather than default) export
+      filePath: '@vue/awesome-components',
+    })
+  },
+})
+```
+
+Alternatively, you can add an entire directory by using `addComponentsDir`.
+
+```ts
+import { addComponentsDir, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    addComponentsDir({
+      path: resolver.resolve('runtime/components'),
+    })
+  },
+})
+```
+
+::tip{icon="i-lucide-lightbulb"}
+It is highly recommended to prefix your exports to avoid conflicts with user code or other modules.
+
+:read-more{to="/docs/4.x/guide/modules/best-practices#prefix-your-exports"}
+::
+
+## Add Composables
+
+If your module should provide composables, you can use the `addImports` utility to add them as auto-imports for Nuxt to resolve.
+
+```ts
+import { addImports, createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    addImports({
+      name: 'useComposable', // name of the composable to be used
+      as: 'useComposable',
+      from: resolver.resolve('runtime/composables/useComposable'), // path of composable
+    })
+  },
+})
+```
+
+Alternatively, you can add an entire directory by using `addImportsDir`.
+
+```ts
+import { addImportsDir, createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    addImportsDir(resolver.resolve('runtime/composables'))
+  },
+})
+```
+
+::tip{icon="i-lucide-lightbulb"}
+It is highly recommended to prefix your exports to avoid conflicts with user code or other modules.
+
+:read-more{to="/docs/4.x/guide/modules/best-practices#prefix-your-exports"}
+::
+
+## Add Server Routes
+
+```ts
+import { addServerHandler, createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    addServerHandler({
+      route: '/api/_my-module/hello',
+      handler: resolver.resolve('./runtime/server/api/hello/index.get'),
+    })
+  },
+})
+```
+
+You can also add a dynamic server route:
+
+```ts
+import { addServerHandler, createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    addServerHandler({
+      route: '/api/_my-module/hello/:name',
+      handler: resolver.resolve('./runtime/server/api/hello/[name].get'),
+    })
+  },
+})
+```
+
+::tip{icon="i-lucide-lightbulb"}
+It is highly recommended to prefix your server routes to avoid conflicts with user-defined routes. Common paths like `/api/auth`, `/api/login`, or `/api/user` may already be used by the application.
+
+:read-more{to="/docs/4.x/guide/modules/best-practices#prefix-your-exports"}
+::
+
+## Add Other Assets
+
+If your module should provide other kinds of assets, they can also be injected. Here's a simple example module injecting a stylesheet through Nuxt's `css` array.
+
+```js
+import { addPlugin, createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    nuxt.options.css.push(resolver.resolve('./runtime/style.css'))
+  },
+})
+```
+
+And a more advanced one, exposing a folder of assets through [Nitro](/docs/4.x/guide/concepts/server-engine)'s `publicAssets` option:
+
+```js
+import { createResolver, defineNuxtModule } from '@nuxt/kit'
+
+export default defineNuxtModule({
+  setup (options, nuxt) {
+    const resolver = createResolver(import.meta.url)
+
+    nuxt.hook('nitro:config', (nitroConfig) => {
+      nitroConfig.publicAssets ||= []
+      nitroConfig.publicAssets.push({
+        dir: resolver.resolve('./runtime/public'),
+        maxAge: 60 * 60 * 24 * 365, // 1 year
+      })
+    })
+  },
+})
+```
+
+## Use Other Modules
+
+If your module depends on other modules, you can specify them using the `moduleDependencies` option. This provides a more robust way to handle module dependencies with version constraints and configuration merging:
+
+```ts
+import { createResolver, defineNuxtModule } from '@nuxt/kit'
+
+const resolver = createResolver(import.meta.url)
+
+export default defineNuxtModule<ModuleOptions>({
+  meta: {
+    name: 'my-module',
+  },
+  moduleDependencies: {
+    '@nuxtjs/tailwindcss': {
+      // You can specify a version constraint for the module
+      version: '>=6',
+      // Any configuration that should override `nuxt.options`
+      overrides: {
+        exposeConfig: true,
+      },
+      // Any configuration that should be set. It will override module defaults but
+      // will not override any configuration set in `nuxt.options`
+      defaults: {
+        config: {
+          darkMode: 'class',
+          content: {
+            files: [
+              resolver.resolve('./runtime/components/**/*.{vue,mjs,ts}'),
+              resolver.resolve('./runtime/*.{mjs,js,ts}'),
+            ],
+          },
+        },
+      },
+    },
+  },
+  setup (options, nuxt) {
+    // We can inject our CSS file which includes Tailwind's directives
+    nuxt.options.css.push(resolver.resolve('./runtime/assets/styles.css'))
+  },
+})
+```
+
+::callout{type="info"}
+The `moduleDependencies` option replaces the deprecated `installModule` function and ensures proper setup order and configuration merging.
+::