贡献

您可以通过多种方式为 Nuxt 生态系统做出贡献。

生态系统

Nuxt 生态系统包括许多不同的项目和组织：

• nuxt/ - Nuxt 框架本身的核心仓库。nuxt/nuxt 包含 Nuxt 框架（包括版本 2 和 3）。
• nuxt-modules/ - 社区贡献和维护的模块和库。有迁移模块到 nuxt-modules 的流程。虽然这些模块有各自的维护者，但它们并不依赖于单一的个人。
• unjs/ - 这些库在 Nuxt 生态系统中广泛使用。它们被设计为通用的、与框架和环境无关的库。我们欢迎其他框架和项目的贡献和使用。

如何贡献

筛选问题并参与讨论

查看您想帮助的项目的 issue 和讨论。例如，这里是 Nuxt 的问题面板和讨论。帮助其他用户、分享解决方法、创建重现、甚至稍微深入研究一个 bug 并分享您的发现，都会产生巨大的影响。

创建一个 Issue

感谢您花时间创建 issue！❤️

• 报告 bug：请查看我们的指南，了解在创建 issue 前需要做的一些事情。
• 功能请求：请确认是否已经存在涵盖您所设想功能范围的 issue 或讨论。如果功能涉及 Nuxt 生态系统的其他部分（例如某个模块），请考虑先在那边提出功能请求。如果您设想的功能较为通用或 API 尚不完全明确，可以考虑在 Ideas 部分开启一个讨论，与社区先进行交流。

我们将尽力遵循我们的内部 issue 决策流程图来回应 issue。

发送 Pull Request

我们始终欢迎 pull request！❤️

在您开始之前

在修复 bug 之前，我们建议您检查是否有一个描述该 bug 的 issue，因为这可能是文档问题，或者有一些有用的背景信息需要了解。

如果您正在开发一个功能，我们要求您先开启一个功能请求 issue，与维护者讨论该功能是否被需要——以及这些功能的设计。这有助于节省维护者和贡献者的时间，并意味着功能可以更快发布。功能请求 issue 需要由框架团队成员确认，然后才能在 pull request 中构建该功能。

对于拼写错误修复，建议将多个拼写修复合并到一个 pull request 中，以保持更清晰的提交历史。

对于 Nuxt 本身的较大更改，我们建议您先创建一个 Nuxt 模块并在那里实现该功能。这允许快速验证概念。然后您可以创建 RFC以讨论形式提出。随着用户采用并收集反馈，可以进一步完善功能，要么将其添加到 Nuxt 核心，要么继续作为独立模块。

提交规范

我们使用 Conventional Commits 作为提交信息规范，这允许基于提交自动生成变更日志。如果您还不熟悉，请仔细阅读相关指南。

请注意，fix: 和 feat: 用于实际代码更改（可能影响逻辑）。对于拼写或文档更改，请使用 docs: 或 chore:：

• fix: typo -> docs: fix typo

如果您在像 nuxt/nuxt 这样的 monorepo 项目中工作，请确保在括号中指定提交的主要范围。例如：feat(nuxi): add 'do-magic' command。

创建 Pull Request

如果您不知道如何发送 pull request，我们建议阅读相关指南。

在发送 pull request 时，请确保 PR 的标题也遵循提交规范。

如果您的 PR 修复或解决了现有 issue，请确保在 PR 描述中提及它们。

一个 PR 中可以包含多个提交，您无需为更改重新 rebase 或强制推送，因为我们会在合并时使用 Squash and Merge 将提交压缩为一个。

我们没有添加任何提交钩子以便于快速提交。但在创建 pull request 之前，您应确保所有 lint/测试脚本都通过。

通常，请确保 PR 中没有_无关_的更改。例如，如果您的编辑器在您编辑的文件中更改了空格或格式，请撤销这些更改，以便更清楚地展示 PR 的变化内容。请避免在一个 PR 中包含多个不相关的功能或修复。如果可以分开，最好创建多个 PR 分别审查和合并。通常，一个 PR 应该只做_一件事_。

在您创建 Pull Request 之后

一旦您创建了 pull request，我们会尽快进行审查。

如果我们将其分配给某个维护者，这意味着该维护者会特别注意审查并实现任何必要的更改。

如果我们在 PR 上请求更改，请忽略红色文本！这并不意味着我们认为这是一个不好的 PR——它只是为了方便快速查看 pull request 列表的状态。

如果我们将 PR 标记为“pending”，这意味着我们可能还有其他任务需要审查 PR——这是一个内部提醒，并不一定反映 PR 是否是一个好主意。我们会尽力通过评论解释“pending”状态的原因。

我们将尽力遵循我们的 PR 决策流程图来回应和审查 pull request。

创建一个模块

如果您用 Nuxt 构建了很酷的东西，为什么不将其提取为一个模块，以便与他人共享？我们已经有了许多优秀的模块，但总有更多空间。

如果您在构建过程中需要帮助，请随时与我们联系。

提出 RFC

我们强烈建议先创建一个模块来测试大型新功能并获得社区的采用。

如果您已经这样做了，或者创建新模块不合适，那么请先创建一个新的讨论。确保尽可能清楚地解释您的想法。包括代码示例或新 API 的函数签名。参考现有的 issue 或痛点并举例说明。

如果我们认为这应该成为一个 RFC，我们会将类别更改为 RFC，并更广泛地传播以获取反馈。

RFC 将经历以下阶段：

• rfc: active - 当前开放评论
• rfc: approved - 由 Nuxt 团队批准
• rfc: ready to implement - 已创建并分配了实现 issue
• rfc: shipped - 已实现
• rfc: archived - 未获批准，但存档以供未来参考

生态系统中的规范

以下规范在 nuxt/ 组织中是_必须遵守_的，并推荐给生态系统中其他维护者使用。

模块规范

模块应遵循 Nuxt 模块模板。更多信息请参见模块指南。

使用核心 unjs/ 库

我们推荐以下在生态系统中广泛使用的库：

• pathe - 通用的路径工具（替代 node path）
• ufo - URL 解析和拼接工具
• unbuild - 基于 rollup 的构建系统
• ... 查看 unjs/ 组织中的更多内容！

使用 ESM 语法并默认设置 type: module

Nuxt 生态系统的大部分内容可以直接使用 ESM。我们通常建议避免使用 CJS 特定的代码，例如 __dirname 和 require 语句。您可以了解更多关于 ESM 的内容。

什么是 Corepack

Corepack 确保您在运行相应命令时使用正确的包管理器版本。项目可能在其 package.json 中包含 packageManager 字段。

在如下配置的项目中，Corepack 将安装 pnpm 的 v7.5.0 版本（如果您尚未安装），并使用它来运行您的命令。

{
  "packageManager": "pnpm@7.5.0"
}

使用 ESLint

我们使用 ESLint 进行代码检查和格式化，配合 @nuxt/eslint。

IDE 设置

我们推荐使用 VS Code 配合 ESLint 扩展。如果您愿意，可以启用保存代码时的自动修复和格式化：

{
  "editor.codeActionsOnSave": {
    "source.fixAll": "never",
    "source.fixAll.eslint": toilexplicit"
  }
}

不使用 Prettier

由于 ESLint 已配置为格式化代码，因此无需使用 Prettier 重复此功能。要格式化代码，您可以运行 yarn lint --fix、pnpm lint --fix 或 bun run lint --fix，或参考 ESLint 部分 的 IDE 设置。

如果您的编辑器中安装了 Prettier，我们建议在项目工作时禁用它，以避免冲突。

包管理器

我们推荐使用 pnpm 作为模块、库和应用的包管理器。

启用 Corepack 很重要，以确保您使用与项目相同的包管理器版本。Corepack 已内置于新版本的 Node.js 中，以实现无缝的包管理器集成。

要启用它，请运行：

corepack enable

您只需在安装 Node.js 后执行一次此操作。

文档风格指南

文档是 Nuxt 的重要组成部分。我们致力于打造一个直观的框架——其中很大一部分是确保开发者体验和整个生态系统的文档都完美无缺。👌

以下是一些可能有助于改进文档的建议：

• 尽可能避免使用主观词汇，如 simply、just、obviously...。
  请记住，您的读者可能有不同的背景和经验。因此，这些词语不传达实际意义，且可能造成不良影响。
  只需确保函数返回一个 promise。
  确保函数返回一个 promise。
• 优先使用主动语态。
  Nuxt 将抛出错误。
  Nuxt 会抛出错误。