贡献

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

生态系统

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

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

如何贡献

分类问题并在讨论中提供帮助

查看您想帮助的项目的 issue 和讨论。例如，以下是在 Nuxt 3 的 issue 板 和 讨论。帮助其他用户，分享解决方法，创建复现，甚至深入研究错误并分享你的发现，都会产生巨大的影响。

创建 Issue

感谢您抽出时间创建 Issue！ ❤️

• 报告错误：查看 我们的指南，了解在打开 Issue 之前可以做的一些事情。
• 功能请求：检查是否有现有的 Issue 或讨论涵盖了您想到的功能范围。如果功能属于 Nuxt 生态系统的其他部分（例如模块），请考虑首先在那里提出功能请求。如果您想到的功能是通用的或者 API 不完全清楚，请考虑在“想法”部分中打开一个讨论，以便首先与社区讨论。

在响应 Issue 时，我们会尽力遵循 内部 Issue 决策流程图。

发送 Pull Request

我们始终欢迎 Pull Request！ ❤️

开始之前

在修复错误之前，我们建议您检查**是否有一个 Issue 描述了它**，因为它可能是文档问题，或者可能存在一些有帮助的上下文信息。

如果您正在处理功能，那么我们要求您**首先打开一个功能请求 Issue**，以便与维护者讨论该功能是否需要 - 以及这些功能的设计。这有助于为维护者和贡献者节省时间，并意味着功能可以更快地发布。在 Pull Request 中构建功能之前，框架团队成员**应该确认**该 Issue。

对于错别字修复，建议将多个错别字修复批量到一个 Pull Request 中，以维护更清晰的提交历史记录。

对于对 Nuxt 本身进行的较大更改，我们建议您首先 创建 Nuxt 模块并在其中实现该功能。这允许快速进行概念验证。然后，您可以 创建 RFC（以讨论的形式）。随着用户采用它并收集反馈，它可以被改进，并添加到 Nuxt 核心或继续作为独立模块。

提交约定

我们使用 Conventional Commits 用于提交消息，这 允许根据提交自动生成更改日志。如果您还不熟悉它，请通读指南。

请注意，fix: 和 feat: 用于实际的代码更改（可能会影响逻辑）。对于错别字或文档更改，请改为使用 docs: 或 chore:

• fix: typo -> docs: fix typo

如果您在一个使用单一存储库的项目中工作，例如 nuxt/nuxt，请确保在括号中指定提交的主要范围。例如：feat(nuxi): add 'do-magic' command。

创建 Pull Request

如果您不知道如何发送 Pull Request，我们建议您阅读 指南。

发送 Pull Request 时，请确保 PR 的标题也遵循 提交约定。

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

在一个 PR 中有多个提交是可以的；您无需重新整理或强制推送更改，因为我们将在合并时使用 Squash and Merge 将提交压缩成一个提交。

我们不添加任何提交钩子以允许快速提交。但在您创建 Pull Request 之前，您应该确保任何 lint/测试脚本都已通过。

通常，也请确保 PR 中没有无关的更改。例如，如果您的编辑器在您编辑的文件的其他位置对空格或格式进行了任何更改，请将其恢复，以便更清楚地了解您的 PR 更改。并且请避免在一个 PR 中包含多个不相关的功能或修复。如果可以将它们分开，最好有多个 PR 分别进行审查和合并。通常，一个 PR 应该只做一件事。

创建 Pull Request 后

创建 Pull Request 后，我们会尽力及时审查。

如果我们将其分配给维护者，则表示该人员将特别注意审查它并实施可能需要的任何更改。

如果我们请求在 PR 上进行更改，请忽略红色文本！这并不意味着我们认为这是一个糟糕的 PR - 它只是一种轻松查看 Pull Request 列表状态的方法。

如果我们将 PR 标记为“待定”，则表示我们可能需要在审查 PR 时执行其他任务 - 这是一个内部备忘，不一定反映 PR 是否是一个好主意。我们会尽力通过评论解释待定状态的原因。

在响应和审查 Pull Request 时，我们会尽力遵循 我们的 PR 决策流程图。

创建模块

如果您使用 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 将安装 v7.5.0 版本的 pnpm（如果您还没有它）并使用它来运行您的命令。

{
  "packageManager": "[email protected]"
}

使用 ESLint

我们使用 ESLint 进行 lint 和格式化，并使用 @nuxt/eslint-config。

IDE 设置

我们建议使用VS Code 以及 ESLint 扩展。如果您愿意，可以在保存正在编辑的代码时启用自动修复和格式化功能。

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

无需 Prettier

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

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

注意：我们正在讨论在未来启用 Prettier 的可能性。

包管理器

对于库，我们建议使用 pnpm。对于模块，我们仍然建议使用 yarn，但一旦我们支持 Nuxt 本身使用即插即用模式，我们很可能会在未来将此建议切换到 pnpm。

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

要启用它，请运行

corepack enable

您只需执行此操作一次，在您的计算机上安装 Node.js 后即可。

文档风格指南

文档是 Nuxt 的重要组成部分。我们的目标是成为一个直观的框架——而实现这一目标很大一部分在于确保开发人员体验和文档在整个生态系统中都完美无缺。👌

以下是一些可能有助于改进您文档的技巧

• 尽可能避免使用诸如“简单地”、“仅仅”、“显然”等主观词语。
  请记住，您的读者可能拥有不同的背景和经验。因此，这些词语并不能传达意义，反而可能造成误解。
  只需确保函数返回一个 Promise 即可。
  确保函数返回一个Promise。
• 优先使用主动语态。
  Nuxt 将抛出一个错误。
  Nuxt 将抛出一个错误。