贡献
你可以通过多种方式为 Nuxt 生态系统做出贡献。
生态系统
Nuxt 生态系统包括许多不同的项目和组织：
- nuxt/ - Nuxt 框架本身的核心仓库。nuxt/nuxt 包含了 Nuxt 框架的版本 2 和 3。
- nuxt-modules/ - 社区贡献和维护的模块和库。有一个迁移模块的过程到
nuxt-modules。虽然这些模块有各自的维护者，但它们不依赖于单个人。 - unjs/ - 许多这些库在 Nuxt 生态系统中被使用。它们被设计为通用库，不依赖于特定的框架和环境。我们欢迎其他框架和项目使用和贡献这些库。
如何贡献
处理问题和参与讨论
查看你想要帮助的项目的问题和讨论。例如，这是 Nuxt 3 的问题面板和讨论。帮助其他用户、分享解决方法、创建示例代码或者稍微调查一下 bug 并分享你的发现都能产生巨大的影响。
创建问题
感谢你花时间创建问题！❤️
- 报告 bug：在创建问题之前，请查看我们的指南，了解一些在报告问题之前需要做的事情。
- 功能请求：请检查是否已有现有的问题或讨论涵盖了你所设想的功能的范围。如果该功能属于 Nuxt 生态系统的其他部分（例如模块），请先考虑在那里提出功能请求。如果你所设想的功能是通用的或者 API 不是完全清晰的，请考虑在想法部分开启一次讨论，与社区共同讨论。
我们将尽力遵循我们的内部问题决策流程图来回应问题。
提交拉取请求
我们总是欢迎拉取请求！❤️
开始之前
在修复 bug 之前，我们建议你检查是否有描述该 bug 的问题，因为可能是文档问题，或者有一些有助于了解背景的上下文信息。
如果你正在开发一个功能，请先创建一个功能请求问题，与维护者讨论该功能是否需要以及功能的设计。这有助于节省维护者和贡献者的时间，并且可以更快地发布功能。在创建拉取请求之前，该问题应该由框架团队成员确认。
对于拼写错误的修复，建议将多个拼写错误修复合并到一个拉取请求中，以保持更清晰的提交历史。
对于对 Nuxt 本身的较大更改，我们建议你首先创建一个 Nuxt 模块，并在那里实现该功能。这样可以快速验证概念。然后，你可以[创建一个 RFC](#创建一个 RFC)，以讨论的形式提出。随着用户的采用和反馈，它可以不断完善，要么被添加到 Nuxt 核心，要么作为一个独立的模块继续存在。
提交约定
我们使用常规提交作为提交信息的格式，这样可以根据提交自动生成变更日志。如果你还不熟悉它，请先阅读指南。
请注意，fix: 和 feat: 是用于实际的代码更改（可能会影响逻辑）。对于拼写或文档更改，请使用 docs: 或 chore:：
fix: typodocs: 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 请求更改，请忽略红色的文本！这并不意味着我们认为这是一个糟糕的 PR - 这只是一种简单地告诉一组拉取请求的状态的方式。
如果我们将一个 PR 标记为“待定”，那意味着我们可能还有其他任务要在审查 PR 时完成 - 这是一个内部的提醒，不一定反映该 PR 是否是一个好主意。我们将尽力通过评论解释“待定”状态的原因。
我们将尽力遵循我们的 PR 决策流程图来回应和审查拉取请求。
创建一个模块
如果你使用 Nuxt 构建了一些很棒的东西，为什么不将其提取为一个模块，以便与他人共享？我们已经有很多优秀的模块，但总是有更多的空间。
如果在构建过程中需要帮助，请随时与我们联系。
创建一个 RFC
我们强烈推荐先创建一个模块来测试大型新功能，并获得社区的采用。
如果你已经完成了这一步，或者创建新模块不合适，那么请先创建一个新的讨论。确保尽可能清楚地解释你的想法。包括新 API 的代码示例或函数签名。引用现有的问题或痛点，并举例说明。
如果我们认为这应该是一个 RFC，我们将把类别更改为 RFC，并广泛广播以获得反馈。
然后，RFC 将经历以下阶段：
rfc: active- 目前接受评论rfc: approved- Nuxt 团队批准rfc: ready to implement- 创建了一个用于实现的问题并进行分配rfc: shipped- 已实现rfc: archived- 未批准，但归档以供将来参考
生态系统中的约定
以下约定在 nuxt/ 组织中是_必需的_，并建议其他维护者在生态系统中也遵循。
模块约定
模块应遵循Nuxt 模块模板。有关更多信息，请参阅模块指南。
使用核心 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-config。
IDE 设置
我们建议使用VS Code与ESLint 扩展一起使用。如果愿意，你可以在保存代码时启用自动修复和格式化：
{
"editor.codeActionsOnSave": {
"source.fixAll": false,
"source.fixAll.eslint": true
}
}
没有 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的重要组成部分。我们的目标是成为一个直观的框架，其中一个重要的方面就是确保开发者体验和文档在整个生态系统中都是完美的。👌
以下是一些可能有助于改进您的文档的提示: