贡献

有多种不同的方式可以贡献到 Nuxt 生态系统。

生态系统

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

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

如何贡献

处理问题和帮助讨论

查看你想要帮助的项目的问题和讨论。例如，这里是问题板和讨论的 Nuxt 3。帮助其他用户，分享绕过方案，创建复现，甚至稍微研究一下一个 bug，分享你的发现，都会有很大的不同。

创建一个问题

感谢你花费时间创建问题！❤️

• 报告 bug： 查看我们的指南在打开一个问题之前做一些事情。
• 功能请求： 检查是否有一个现有问题或讨论覆盖了你所想到的特征的范围。如果特征是针对生态系统的其他部分（如模块），请考虑先在那个地方提出功能请求。如果你所想到的特征是通用的，或者 API 不是很清楚，可以考虑在 Ideas 部分打开一个讨论，先与社区讨论。

我们会尽最大努力遵循内部问题决策流程图来回应问题。

发送一个拉取请求

我们总是欢迎拉取请求！❤️

在你开始之前

在你修复一个 bug 之前，我们建议你检查一下 是否有一个问题描述它，因为这可能是文档问题，或者有一些上下文会很有帮助。

如果你正在做一个特性，那么我们要求你 先打开一个特性请求问题 来与维护者讨论是否想要这个特性 —— 以及这些特性的设计。这有助于节省维护者和贡献者的时间，意味着特性可以更快地被交付。问题 应该得到 框架团队成员的确认，然后再在拉取请求中构建特性。

对于打字错误修复，建议将多个打字错误修复合并到一个拉取请求中以保持更干净的提交历史。

对于 Nuxt 本身的大变化，我们建议你首先创建一个 Nuxt 模块并在这个模块中实现特性。这允许快速的概念验证。你可以创建一个 RFC，以讨论的形式。随着用户采纳它，你可以收集反馈，然后可以改进它，并将其添加到 Nuxt 核心或继续作为一个独立的模块。

提交约定

我们使用符合规范的提交作为提交消息，这允许根据提交自动生成变更日志。如果你不熟悉它，请在打开问题之前阅读指南。

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

• fix: typo -> docs: fix typo

如果你在一个有单仓库的项目中工作，比如 nuxt/nuxt，请确保你指定你提交的主要范围。例如：feat(nuxi): add 'do-magic' command。

制作拉取请求

如果你不知道如何发送拉取请求，我们建议你阅读指南。

当发送拉取请求时，请确保你的 PR 的标题也遵循提交公约。

如果你的 PR 修复或解决了现有问题，请确保你在 PR 描述中提到它们。

在没有多个无关的更改在一个 PR 中；你不需要为了你的更改而重新整理或强制推送，我们将使用 Squash and Merge 来挤压合并提交当合并时。

我们不会添加任何提交钩来允许快速提交。但在你制作拉取请求之前，你应该确保任何 Lint/Test 脚本都通过。

总的来说，请确保 PR 中没有 无关的更改。例如，如果你编辑器在其他地方编辑的文件做了任何更改，比如空白或格式化，请将这些更改复位，以便它更明显你的 PR 更改。请避免在一个单独的 PR 中包括多个不相关的特性或修复。如果可能的话，将它们分开，让它们单独审查和合并。一般来说，一个 PR 应该做 一件事。

一旦你做了拉取请求

一旦你做了拉取请求，我们将尽最大努力尽快审查它。

如果我们指派它给维护者，这意味着那个人将会特别注意审查它并实施可能需要的任何更改。

如果我们要求拉取请求上的更改，请忽略红色文字！它并不意味着我们认为它是一个糟糕的 PR —— 它只是一种方式，很容易一眼就看到一长串拉取请求的状态。

如果我们标记一个 PR 为 'pending'，这意味着我们可能有一些审查 PR 的任务——这是一个内部备忘，不一定反映拉取请求是否是一个好主意。我们将尽最大努力通过评论解释等待状态的原因。

我们将尽最大努力遵循我们的 PR 决策流程图回应和审查拉取请求。

创建一个模块

如果你已经构建了 Nuxt 的某些酷东西，为什么不提取它到一个模块，以便它可以与其他用户共享？我们的模块库中已经有很多优秀的模块，但是总会有更多的空间。

如果你在构建它时需要帮助，请自由地与我们检查一下。

制作一个 RFC

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

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

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

RFC 将通过以下阶段：

• rfc: active - 目前开放评论
• rfc: approved - 由 Nuxt 团队批准
• rfc: ready to implement - 创建了一个问题并分配了实现
• 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": "pnpm@7.5.0"
}

使用 ESLint

我们使用 ESLint 来进行 linting 和格式化，使用 @nuxt/eslint。

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，我们建议您在处理项目时禁用它，以避免冲突。

包管理器

对于库，我们推荐使用 pnpm。对于模块，我们仍然推荐使用 yarn，但一旦我们支持与 Nuxt 本身的即插即用模式，我们可能会将此推荐更改为 pnpm。

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

要启用它，请运行

corepack enable

你只需要在你电脑上安装 Node.js 一次。

文档样式指南

文档是 Nuxt 的一个关键部分。我们的目标是成为一个直观的框架——这很大程度上取决于确保开发体验和文档都是完美的跨生态系统。👌

以下是一些可能有助于改进你的文档的小贴士：

• 避免使用主观词汇，如 简单地，只是，显然...，如果可能的话。
  记住你的读者可能有不同的背景和经验。因此，这些词不传达意义，并且可能是有害的。
  直接确保函数返回一个 Promise。
  确保函数返回一个 Promise。
• 偏好主动语态。
  Nuxt 会抛出一个错误。
  Nuxt 会抛出一个错误。