贡献指南
您可以通过多种不同方式为 Nuxt 生态系统做出贡献。
生态系统
Nuxt 生态系统包含多个不同项目和组织：
- nuxt/ - Nuxt 框架核心仓库。nuxt/nuxt 包含 Nuxt 框架（2.x 和 3.x 版本）
- nuxt-modules/ - 社区贡献和维护的模块与库。迁移模块到
nuxt-modules有标准流程。这些模块由独立维护者管理，不依赖单一个人 - unjs/ - 许多通用库被用于 Nuxt 生态系统。这些库设计为框架和环境无关的通用库，欢迎其他框架和项目贡献和使用
如何贡献
处理问题与参与讨论
查看您想帮助项目的议题和讨论区。例如 Nuxt 的议题看板和讨论区。帮助其他用户、分享解决方案、创建复现示例，甚至简单研究错误并分享发现，都能产生巨大影响。
创建议题
感谢您花时间创建议题！❤️
- 错误报告：请先查阅我们的指南了解创建议题前的准备工作
- 功能请求：请确认没有现有议题或讨论涵盖您设想的功能范围。如果功能属于 Nuxt 生态系统其他部分（如模块），请先在那里提交请求。如果功能较为通用或 API 设计不明确，建议先在 Ideas 分类创建讨论与社区交流
我们会遵循内部议题决策流程图处理议题
提交拉取请求
我们始终欢迎拉取请求！❤️
准备工作
修复错误前，建议先检查是否有相关议题，因为这可能是文档问题或需要了解相关背景。
开发新功能时，请先创建功能请求议题与维护者讨论功能需求与设计。这能节省双方时间并加速功能发布。框架团队成员需确认议题后再通过拉取请求实现功能。
对于拼写错误修复，建议将多个修复合并到一个拉取请求中，以保持提交历史清晰。
对于 Nuxt 本身的重大变更，建议先创建 Nuxt 模块实现功能原型，然后创建 RFC 讨论。待用户采用并收集反馈后，可将其精炼并加入 Nuxt 核心或保持为独立模块。
提交规范
我们使用约定式提交规范提交信息，这能自动生成变更日志。如不熟悉请先阅读指南。
注意 fix: 和 feat: 用于实际代码变更（可能影响逻辑）。拼写或文档变更使用 docs: 或 chore:：
fix: typodocs: fix typo
若在 monorepo 项目（如 nuxt/nuxt）中工作，请在提交信息括号内指定主要范围。例如：feat(kit): add 'addMagicStuff' utility
创建拉取请求
如不熟悉拉取请求流程，建议阅读GitHub 指南
拉取请求标题也应遵循提交规范
若 PR 修复了现有问题，请在描述中提及相关议题
单个 PR 可包含多次提交，无需变基或强制推送，我们将使用 Squash and Merge 在合并时压缩提交
虽然我们未设置提交钩子，但在创建 PR 前请确保通过所有 lint/测试脚本
通常请确保 PR 中不包含无关变更。例如若编辑器自动修改了文件空白或格式，请撤销这些变更以突出实际修改内容。尽量避免在单个 PR 中包含多个无关功能或修复。如能分离，最好分多个 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/ 组织内为必需，推荐其他生态维护者采用
模块规范
使用核心 unjs/ 库
我们推荐以下生态通用库：
使用 ESM 语法并默认 type: module
Nuxt 生态大多可直接使用 ESM。通常建议避免使用 CJS 特定代码，如 __dirname 和 require 语句。了解更多 ESM 信息
关于 Corepack
Corepack 确保运行命令时使用正确的包管理器版本。项目可能在 package.json 中包含 packageManager 字段
如下配置的项目中，Corepack 会自动安装 pnpm@7.5.0（如未安装）并用于运行命令
{
"packageManager": "pnpm@7.5.0"
}
使用 ESLint
我们使用 ESLint 进行代码检查和格式化，配合 @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.js 实现无缝集成
运行以下命令启用：
corepack enable
只需在安装 Node.js 后执行一次
文档风格指南
文档是 Nuxt 的重要组成部分。我们致力于成为直观的框架——其中关键环节是确保整个生态系统的开发体验和文档完美。👌
以下技巧可帮助改进文档：