您可以通过多种不同的方式为 Nuxt 生态系统做出贡献。
Nuxt 生态系统包括许多不同的项目和组织
nuxt-modules 有一个过程。虽然这些模块有独立的维护者，但它们不依赖于某一个人。查看您想要提供帮助的项目的 issue 和 discussion。例如，这是 Nuxt 的问题板等等讨论。帮助其他用户、分享变通方法、创建复现或甚至深入研究一个 bug 并分享您的发现都会产生巨大的影响。
感谢您花时间创建问题！❤️
我们将尽最大努力遵循我们的内部问题决策流程图来响应问题。
我们始终欢迎拉取请求！❤️
在修复 bug 之前，我们建议您检查是否存在描述该 bug 的问题，因为它可能是文档问题，或者可能有一些有用的背景信息。
如果您正在开发一个功能，我们要求您首先开启一个功能请求问题，与维护者讨论该功能是否需要——以及这些功能的设计。这有助于节省维护者和贡献者的时间，并意味着功能可以更快地发布。该问题应由框架团队成员确认，然后才能在拉取请求中构建功能。
对于拼写错误修复，建议将多个拼写错误修复批处理到一个拉取请求中，以保持更清晰的提交历史。
对于 Nuxt 本身较大的更改，我们建议您首先创建一个 Nuxt 模块并在其中实现该功能。这允许快速概念验证。然后，您可以以讨论的形式创建一个 RFC。随着用户采用并收集反馈，它可以在之后进行完善，并添加到 Nuxt 核心或继续作为一个独立的模块。
我们使用Conventional Commits用于提交消息，这允许自动生成变更日志基于提交。如果您还不熟悉，请通读指南。
请注意，fix: 和 feat: 用于实际代码更改（可能影响逻辑）。对于拼写错误或文档更改，请使用 docs: 或 chore: 代替。
fix: typodocs: fix typo如果您在一个 monorepo 项目中工作，例如 nuxt/nuxt，请确保在括号中指定提交的主要范围。例如：feat(kit): add 'addMagicStuff' utility。
如果您不知道如何发送拉取请求，我们建议阅读指南.
发送拉取请求时，请确保您的 PR 标题也遵循提交约定。
如果您的 PR 修复或解决了现有问题，请确保在 PR 描述中提及它们。
单个 PR 中有多个提交是可以的；您无需为了更改而 rebase 或 force push，因为我们会在合并时使用 Squash and Merge 将提交压缩成一个。
我们不添加任何 commit hooks 以便快速提交。但在您创建拉取请求之前，您应该确保所有 lint/test 脚本都通过。
通常，请确保 PR 中没有不相关的更改。例如，如果您的编辑器对您编辑的文件中其他位置的空白或格式进行了任何更改，请将其还原，以便更清楚您的 PR 更改了什么。并且请避免在单个 PR 中包含多个不相关的功能或修复。如果可以将它们分开，最好有多个 PR 分别进行审查和合并。通常，一个 PR 应该只做一件事。
一旦您提交了拉取请求，我们将尽力及时进行审查。
如果我们将它分配给维护者，则意味着该维护者将特别负责审查它并实施可能需要的任何更改。
如果我们请求对 PR 进行更改，请忽略红色文本！这并不意味着我们认为这是一个糟糕的 PR——这只是一种可以一目了然地轻松了解一组拉取请求状态的方式。
如果我们将 PR 标记为“待处理”，这意味着我们可能在审查 PR 时还有其他任务要做——这是一个内部便笺，不一定反映 PR 是否是个好主意。我们将尽力通过评论解释待处理状态的原因。
我们将尽力遵循我们的 PR 决策流程图在响应和审查拉取请求时。
我们欢迎在为 Nuxt 贡献时深思熟虑地使用 AI 工具，但要求所有贡献者遵守两个核心原则.
我们的目标是确保质量并保持与真实人员协作和交流的乐趣。如果您对改进 Nuxt 社区的 AI 政策有任何想法，我们很乐意倾听！❤️
如果您使用 Nuxt 构建了很酷的东西，为什么不将其提取为模块，以便与他人共享呢？我们已经有许多优秀的模块，但总有更多空间。
如果您在构建时需要帮助，请随时联系我们。
我们强烈建议您先创建一个模块，以测试大型新功能并获得社区认可。
如果您已经完成此操作，或者创建新模块不合适，请首先创建一个新讨论。确保尽可能清楚地解释您的想法。包括新 API 的代码示例或函数签名。引用现有问题或痛点并提供示例。
如果我们认为这应该是一个 RFC，我们会将类别更改为 RFC 并更广泛地传播以征求反馈。
一个 RFC 将经历以下阶段
rfc: active - 当前开放评论rfc: approved - 经 Nuxt 团队批准rfc: ready to implement - 已创建问题并分配实现者rfc: shipped - 已实现rfc: archived - 未获批准，但已存档以供将来参考以下约定在 nuxt/ 组织内是必需的，并建议生态系统中的其他维护者遵循。
模块应遵循Nuxt 模块模板。有关更多信息，请参阅模块指南。
unjs/ 库我们推荐以下在整个生态系统中使用到的库
type: module大多数 Nuxt 生态系统可以直接使用 ESM。一般来说，我们提倡您避免使用 CJS 特定的代码，例如 __dirname 和 require 语句。您可以阅读更多关于 ESM 的信息。
Corepack确保您在运行相应命令时使用正确版本的包管理器。项目可能在它们的 package.json 中包含 packageManager 字段。
在配置如下所示的项目中，Corepack 将安装 v7.5.0 版本的 pnpm（如果您还没有安装）并使用它来运行您的命令。
{
"packageManager": "[email protected]"
}
我们使用ESLint同时进行代码检查和格式化，并配合@nuxt/eslint.
我们推荐使用VS Code以及ESLint 扩展。如果您愿意，可以在保存正在编辑的代码时启用自动修复和格式化
{
"editor.codeActionsOnSave": {
"source.fixAll": "never",
"source.fixAll.eslint": "explicit"
}
}
由于 ESLint 已经配置为格式化代码，因此无需使用 Prettier 重复此功能。要格式化代码，您可以运行 yarn lint --fix、pnpm lint --fix 或 bun run lint --fix，或者参阅ESLint 部分进行 IDE 设置。
如果您在编辑器中安装了 Prettier，我们建议您在项目上工作时禁用它以避免冲突。
我们推荐使用 pnpm 作为模块、库和应用程序的包管理器。
重要的是要启用 Corepack，以确保您使用的包管理器版本与项目相同。Corepack 内置于新的 Node 版本中，可实现无缝的包管理器集成。
要启用它，请运行
corepack enable
您只需在计算机上安装 Node.js 后执行一次此操作。
文档是 Nuxt 不可或缺的一部分。我们的目标是成为一个直观的框架——其中很大一部分是确保开发者体验和整个生态系统的文档都完美无缺。👌
以下是一些可能有助于改进您的文档的提示