贡献
您可以通过多种方式为 Nuxt 生态系统做出贡献。
生态系统
Nuxt 生态系统包括许多不同的项目和组织：
- nuxt/ - Nuxt 框架本身的核心代码库。 nuxt/nuxt 包含 Nuxt 框架（版本 2 和 3）。
- nuxt-modules/ - 社区贡献和维护的模块和库。 有一个迁移模块的流程到
nuxt-modules。虽然这些模块有各自的维护者，但并不依赖于单个人。 - unjs/ - 这些库在 Nuxt 生态系统中广泛使用。它们被设计为与框架和环境无关的通用库。我们欢迎其他框架和项目的贡献和使用。
如何贡献
处理问题并参与讨论
查看您想要帮助的项目的问题和讨论。例如，这里是 Nuxt 的问题板 和 讨论。帮助其他用户，分享解决方法，创建重现案例，或者稍微探讨一下错误并分享您的发现，都会有很大的帮助。
创建问题
感谢您花时间创建问题！❤️
- 报告漏洞：在打开问题之前，请查看 我们的指南 中的一些建议。
- 功能请求：检查是否已经存在涵盖您想法的功能的问题或讨论。如果这个功能涉及 Nuxt 生态系统的其他部分（例如模块），请考虑先在那儿提出功能请求。如果您想的功能是普通的或者 API 不完全清晰，请考虑在 想法 部分开启一个讨论，以便和社区先讨论。
我们将尽力遵循 我们内部的问题决策流程图 在回复问题时。
发送拉取请求
我们始终欢迎拉取请求！❤️
在开始之前
在修复漏洞之前，我们建议您检查是否 有一个描述它的问题，因为可能这是一个文档问题或者有一些有用的上下文。
如果您正在开发一个功能，我们要求您 首先打开一个功能请求问题，以与维护者讨论该功能是否受欢迎，以及这些功能的设计。这可以节省维护者和贡献者的时间，并意味着功能可以更快地交付。在拉取请求中构建功能之前，问题 应该得到框架团队成员的确认。
对于拼写错误修复，建议将多个拼写错误修复批量到一个拉取请求中，以保持更清晰的提交历史。
对于对 Nuxt 本身的较大更改，我们建议您首先 创建一个 Nuxt 模块 并在其中实现功能。这允许快速的概念证明。然后您可以在以讨论的形式 创建一个 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 决策流程图 在回复和审查拉取请求时。
创建模块
如果您用 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 进行 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 作为模块、库和应用程序的包管理器。
启用 Corepack 至关重要，以确保您与项目使用同一版本的包管理器。Corepack 已内置于新版本的 Node，以便无缝集成包管理器。
要启用它，请运行
corepack enable
您只需在计算机上安装 Node.js 后执行此操作一次。
文档风格指南
文档是 Nuxt 的重要组成部分。我们旨在成为一个直观的框架，而这一点很大程度上取决于确保开发者体验和文档在整个生态系统中都是完美的。👌
以下是一些可能有助于改善您文档的提示：