理解模块结构

了解 Nuxt 模块的结构以及如何定义它们。

Nuxt 模块有两种类型

无论哪种情况,它们的工作方式都是相同的。

定义你的模块

使用入门模板时,你的模块定义位于 src/module.ts

模块定义是模块的入口点。当你的模块在 Nuxt 配置中被引用时,它会被 Nuxt 加载。

从底层来看,Nuxt 模块定义是一个简单的(可能是异步的)函数,它接受内联的用户选项和一个用于与 Nuxt 交互的 nuxt 对象。

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')
  })
}

你可以使用 Nuxt Kit 提供的更高级的 defineNuxtModule 助手来获取该函数的类型提示。

import { defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule((options, nuxt) => {
  nuxt.hook('pages:extend', (pages) => {
    console.log(`Discovered ${pages.length} pages`)
  })
})

然而,我们不建议直接使用这种底层函数定义。相反,为了定义模块,我们建议使用带有 meta 属性的对象语法来标识你的模块,特别是在发布到 npm 时。

该助手通过实现模块所需的许多常见模式,使编写 Nuxt 模块变得更加直观,既保证了未来的兼容性,又改善了模块作者和用户的使用体验。

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 返回一个带有底层 (inlineOptions, nuxt) 模块签名的包装函数。此包装函数在调用你的 setup 函数之前,会应用默认值并执行其他必要步骤。

  • 支持 defaultsmeta.configKey 以自动合并模块选项
  • 提供类型提示和自动类型推断
  • 通过从 meta.namemeta.configKey 计算出的唯一键,确保模块仅被安装一次
  • 自动注册 Nuxt 钩子
  • 根据模块元数据自动检查兼容性问题
  • 为 Nuxt 内部使用暴露 getOptionsgetMeta
  • 只要模块使用最新版本的 @nuxt/kit 中的 defineNuxtModule,就能确保向后和向上的兼容性
  • 与模块构建工具集成

添加运行时代码

使用入门模板时,运行时目录为 src/runtime/

像 Nuxt 配置中的所有内容一样,模块本身不包含在你的应用运行时中。但是,你可能希望你的模块向安装它的应用提供或注入运行时代码。这就是运行时目录的作用。

在运行时目录中,你可以提供与 Nuxt 应用相关的任何资源:

对于 服务器引擎 Nitro:

  • API 路由
  • 中间件
  • Nitro 插件

或者你想注入到用户 Nuxt 应用中的任何其他类型的资源

  • 样式表
  • 3D 模型
  • 图片
  • 等等。

然后,你可以从你的模块定义中将所有这些资源注入到应用中。.

配方部分了解更多关于资源注入的信息。
发布版模块无法利用其运行时目录内资源的自动导入(auto-imports)。相反,它们必须从 #imports 或类似路径显式导入它们。

出于性能原因,自动导入不适用于 node_modules(已发布模块最终所在的位置)内的文件。