贡献
有许多不同的方式可以为 Nuxt 生态系统做出贡献。
生态系统
Nuxt 生态系统包含许多不同的项目和组织：
- nuxt/ - Nuxt 框架本身的核心仓库。nuxt/nuxt 包含 Nuxt 框架（包括 2 和 3 两个版本）。
- nuxt-modules/ - 社区贡献并维护的模块和库。有一个将模块迁移到
nuxt-modules的流程。虽然这些模块有各自的维护者，但它们不依赖于单一人员。 - unjs/ - 许多这些库在 Nuxt 生态系统中被广泛使用。它们被设计为通用库，与框架和运行环境无关。我们欢迎其他框架和项目的贡献和使用。
如何贡献
分类问题并参与讨论
查看你想要帮助的项目的 issues 和 discussions。例如，这是 Nuxt 的issues 面板和discussions。帮助其他用户、分享变通方案、创建可复现的示例，或者稍微研究一个 bug 并分享你的发现，都会产生巨大的影响。
创建 Issue
感谢你抽时间创建 Issue！❤️
- 报告错误：在打开 Issue 之前，请查看我们的指南以了解在提交前可以做的一些事情。
- 功能请求：请先检查是否已有现成的 issue 或 discussion 涵盖了你想要的功能范围。如果该功能属于 Nuxt 生态系统的其他部分（例如某个模块），请先考虑在对应仓库提交功能请求。如果你设想的功能比较通用或 API 尚不明确，建议先在 Ideas 区域开启一个 discussion 与社区讨论。
在响应 Issues 时，我们会尽量遵循我们的内部问题决策流程图。
提交 Pull Request
我们始终欢迎 Pull Requests！❤️
在开始之前
在修复 bug 之前，建议先检查是否已有描述该问题的 issue，因为它可能是文档问题或存在一些有用的上下文信息。
如果你在开发一个新功能，我们要求你先打开功能请求的 issue，与维护者讨论该功能是否被需要以及功能的设计。这可以为维护者和贡献者节省时间，并能让功能更快地发布。issue 需要由框架团队成员确认，才建议在 PR 中实现该功能。
对于拼写或错别字修复，建议将多个拼写修复合并为一个 Pull Request，以保持提交历史的整洁。
对于对 Nuxt 本身的较大更改，我们建议你先创建一个 Nuxt 模块并在其中实现该功能。这有助于快速验证概念。然后你可以以 discussion 的形式创建 RFC。在用户采用并收集反馈后，可以进一步完善并将其合并到 Nuxt 核心或继续作为独立模块存在。
提交规范
我们在提交信息中使用 Conventional Commits，这可以基于提交自动生成变更日志。如果你不熟悉，请阅读该指南。
注意，fix: 和 feat: 应用于实际的代码更改（可能会影响逻辑）。对于拼写或文档更改，请使用 docs: 或 chore:：
fix: typodocs: fix typo
如果你在像 nuxt/nuxt 这样的 monorepo 项目中工作，请确保在提交时在括号中指定主要作用域。例如：feat(kit): add 'addMagicStuff' utility。
提交 Pull Request
如果你不知道如何发起 Pull Request，建议阅读该指南。
发起 PR 时，请确保 PR 的标题也遵循提交规范。
如果你的 PR 修复或解决了现有 issue，请在 PR 描述中提及它们。
一个 PR 中有多个提交是可以接受的；你不需要为你的变更 rebase 或强制推送，因为我们在合并时会使用 Squash and Merge 将这些提交压缩为一个提交。
我们不会添加任何提交钩子以便快速提交。但是在创建 PR 之前，请确保任何 lint/test 脚本都是通过的。
通常，请确保 PR 中没有无关的更改。例如，如果你的编辑器在你编辑的文件的其他地方更改了空格或格式，请还原这些更改，以便更清楚地看出你的 PR 做了哪些更改。并请避免在单个 PR 中包含多个不相关的功能或修复。如果可以拆分，最好分别提交多个 PR 以便单独审查和合并。一般来说，PR 应该只做“一件事”。
提交 PR 后
创建 PR 后，我们会尽力尽快进行审查。
如果我们把 PR 指派给某位维护者，表示该人会特别负责审查并按需实现变更。
如果我们在 PR 上请求了更改，请别被红色文字吓到！这并不意味着我们认为这是个糟糕的 PR —— 这只是方便快速查看一系列 PR 状态的方式之一。
如果我们将 PR 标记为“pending”，这意味着在审查该 PR 时我们可能还有其他任务要做 —— 这是内部的备忘，并不一定反映该 PR 是否是个好想法或有问题。我们会尽力通过评论解释 pending 状态的原因。
在响应和审阅 Pull Request 时，我们也会尽量遵循我们的 PR 决策流程图。
AI 辅助的贡献
我们欢迎在为 Nuxt 做贡献时审慎地使用 AI 工具，同时要求所有贡献者遵循两个核心原则。
不要让 LLM 代你发声
- 所有评论、issue 和 PR 描述应以你自己的语言撰写
- 我们重视清晰、有人情味的沟通，而非完美的语法或拼写
- 避免直接复制粘贴 AI 生成但并不反映你自身理解的摘要
不要让 LLM 替你思考
- 可以自由使用 AI 工具来生成代码或探索想法
- 仅提交你完全理解并能解释的贡献
- 贡献应当反映你自己的推理和问题解决过程
我们的目标是确保质量并保持与真实人物协作和沟通的乐趣。如果你有改进 Nuxt 社区 AI 使用政策的想法，我们非常愿意听取！❤️
创建模块
如果你用 Nuxt 构建了很酷的东西，为什么不把它提取为一个模块，与他人共享呢？我们已经有许多优秀的模块，但总有更多空间。
如果在构建过程中需要帮助，欢迎随时与我们取得联系。
制定 RFC
我们强烈建议先创建一个模块来测试大型新功能并获得社区采用。
如果你已经这么做了，或者创建新模块不合适，请先创建一个新的 discussion。确保尽可能清晰地说明你的思路。为新的 API 包含代码示例或函数签名，并引用现有的问题或痛点示例。
如果我们认为这应该成为 RFC，我们会将类别更改为 RFC 并更广泛地征求反馈。
RFC 将经历以下阶段：
rfc: active- 正在征求评论rfc: approved- 已被 Nuxt 团队批准rfc: ready to implement- 已创建并分配实现的 issuerfc: shipped- 已实现rfc: archived- 未被批准，但归档以备将来参考
生态系统中的约定
以下约定在 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 来做 lint 和格式化。
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 的重要组成部分。我们力求成为一个直观的框架 —— 而这很大程度上取决于开发者体验和文档在整个生态系统中的完备程度。👌
下面是一些可能有助于改进文档的建议：
