跳至主要内容

拉取请求

请参阅 本地开发 了解有关如何开始本地开发的详细信息。

所以您在本地有一些更改来解决问题?太棒了!

请不要

  • 在打开 PR 后强制推送
    • 原因:GitHub 无法跟踪强制推送中的更改,这会延长我们进行增量审查的时间
  • 在现有 PR 上评论要求更新
    • 原因:您的 PR 并没有被遗忘!志愿者维护者在项目上的时间有限,他们会尽快处理。
      • 一个例外:如果一个 PR 在向维护者提问后被阻塞了 3 个月或更长时间,请提醒我们 - 我们可能已经遗忘了它。
  • 在已关闭的 PR 上评论
    • 原因:如果将问题发布为问题,维护者更容易跟踪。如果您认为 typescript-eslint 中存在错误,正确的做法是提交一个新问题。问题模板包含有用的和必要的做法,例如确保您使用的是所有软件包的最新版本。您可以提供相关 PR 的链接以添加更多上下文。

测试更改

代码覆盖率

我们力争在所有 PR 中实现 100% 的代码覆盖率,但 website/ 包除外。每次运行 yarn test 时,都会在本地生成覆盖率报告。

codecov 机器人也会在每个 PR 上评论其百分比,以及指向 PR 触及的每个文件的逐行覆盖率的链接。

细粒度单元测试

大多数包中的大多数测试都设置为小型、独立的单元测试。我们通常更喜欢这样做,以保持测试及其失败报告的粒度。

对于规则测试,我们建议,在合理的情况下

  • 在大多数影响规则行为的 PR 中包含 validinvalid 代码更改
  • 每个 invalid 案例限制为一个错误

提出 PR

您的更改准备就绪后,就可以提出 PR 了!🙌 您的 PR 标题应符合以下格式

<type>(<package>): <short description>

您可以在 main 的最近提交 中找到更多优质 PR 标题的示例。

  • fix(scope-manager): 正确处理类静态块
  • docs: 修复 README.md 中的入门链接

在您的 PR 内容中,请确保您引用了您所处理的问题,并指出您希望我们在审查期间注意的任何事项。

我们不关心您的历史记录中的提交数量或样式,因为我们将每个 PR 都压缩合并到 main 中。您可以随意使用您觉得舒适的任何样式进行提交。

提示:从 main 以外的分支发送 PR。有关更多信息,请参阅 GitHub 的 建议更改文档

type

必须是以下之一

  • docs - 仅更改文档,而不是发布的代码
  • feat - 任何新的功能添加
  • fix - 任何不添加新功能的错误修复
  • test - 仅更改测试,而不是发布的代码
  • chore - 其他任何事项

package

您所做更改的包的名称(例如 eslint-pluginparsertypescript-estree)。如果您对多个包进行了重大更改,则可以省略此项(例如 feat: foo bar)。

简短描述

PR 的简洁标题。

解决反馈及其他

您的 PR 提交后,CI 通过后,您的 PR 将 等待排队审查。我们通常按照从旧到新的顺序审查 PR,除非我们认为较新的 PR 优先级更高(例如,如果它是错误修复)。

在我们审查您的 PR 后,我们将提供任何需要解决的反馈。如果您认为请求的更改是错误的,请不要害怕在评论中与我们讨论。

请尽可能以行内评论的形式发表评论,以便进行线程化讨论。当您认为讨论已解决时,您可以解决对话,无需明确评论或等待维护者。

在您通过代码更改解决了我们所有的反馈或开始了后续讨论后,请重新请求每个您已解决其反馈的维护者的审查。

一旦反馈得到解决,并且 PR 被批准,我们将确保分支与 main 保持同步,并为您合并它。

随着时间的推移更新

您通常不需要将 main 中的提交合并到您的 PR 分支中。如果您看到合并冲突或其他让您担心的交叉,那么您可以先发制人地进行合并,但这只是可选的。

如果我们认为需要解决合并冲突才能合并或审查 PR,我们可能会出于礼貌为您解决,如果我们有时间。如果没有,我们可能会要求您这样做。

提出问题

如果您需要帮助或有疑问,在 PR 中发表评论是一个很好的方法。无需单独标记任何人。我们中的一员会在我们有时间的时候来帮忙。


感谢信

感谢您完整阅读此文件!请在您的拉取请求底部包含您最喜欢的表情符号,以暗示您确实阅读了此文件。💖 是一个不错的起点,如果您不确定使用哪个表情符号。