拉取请求
请参阅 本地开发 了解有关如何开始本地开发的详细信息。
所以您在本地有一些更改来解决问题?太棒了!
请
- 只发送解决 标记为
accepting prs
的开放、未分配问题 的拉取请求- 一个例外:极其轻微的文档拼写错误
- 请完整填写拉取请求模板
- 在取消草稿 PR之前,请根据开发 > 验证更改验证您的更改
请不要
- 在打开 PR 后强制推送
- 原因:GitHub 无法跟踪强制推送中的更改,这会延长我们进行增量审查的时间
- 在现有 PR 上评论要求更新
- 原因:您的 PR 并没有被遗忘!志愿者维护者在项目上的时间有限,他们会尽快处理。
- 一个例外:如果一个 PR 在向维护者提问后被阻塞了 3 个月或更长时间,请提醒我们 - 我们可能已经遗忘了它。
- 原因:您的 PR 并没有被遗忘!志愿者维护者在项目上的时间有限,他们会尽快处理。
- 在已关闭的 PR 上评论
- 原因:如果将问题发布为问题,维护者更容易跟踪。如果您认为 typescript-eslint 中存在错误,正确的做法是提交一个新问题。问题模板包含有用的和必要的做法,例如确保您使用的是所有软件包的最新版本。您可以提供相关 PR 的链接以添加更多上下文。
测试更改
代码覆盖率
我们力争在所有 PR 中实现 100% 的代码覆盖率,但 website/
包除外。每次运行 yarn test
时,都会在本地生成覆盖率报告。
codecov
机器人也会在每个 PR 上评论其百分比,以及指向 PR 触及的每个文件的逐行覆盖率的链接。
细粒度单元测试
大多数包中的大多数测试都设置为小型、独立的单元测试。我们通常更喜欢这样做,以保持测试及其失败报告的粒度。
对于规则测试,我们建议,在合理的情况下
- 在大多数影响规则行为的 PR 中包含
valid
和invalid
代码更改 - 每个
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-plugin
、parser
、typescript-estree
)。如果您对多个包进行了重大更改,则可以省略此项(例如 feat: foo bar
)。
简短描述
PR 的简洁标题。
解决反馈及其他
您的 PR 提交后,CI 通过后,您的 PR 将 等待排队审查。我们通常按照从旧到新的顺序审查 PR,除非我们认为较新的 PR 优先级更高(例如,如果它是错误修复)。
在我们审查您的 PR 后,我们将提供任何需要解决的反馈。如果您认为请求的更改是错误的,请不要害怕在评论中与我们讨论。
请尽可能以行内评论的形式发表评论,以便进行线程化讨论。当您认为讨论已解决时,您可以解决对话,无需明确评论或等待维护者。
在您通过代码更改解决了我们所有的反馈或开始了后续讨论后,请重新请求每个您已解决其反馈的维护者的审查。
一旦反馈得到解决,并且 PR 被批准,我们将确保分支与 main
保持同步,并为您合并它。
随着时间的推移更新
您通常不需要将 main
中的提交合并到您的 PR 分支中。如果您看到合并冲突或其他让您担心的交叉,那么您可以先发制人地进行合并,但这只是可选的。
如果我们认为需要解决合并冲突才能合并或审查 PR,我们可能会出于礼貌为您解决,如果我们有时间。如果没有,我们可能会要求您这样做。
提出问题
如果您需要帮助或有疑问,在 PR 中发表评论是一个很好的方法。无需单独标记任何人。我们中的一员会在我们有时间的时候来帮忙。
感谢您完整阅读此文件!请在您的拉取请求底部包含您最喜欢的表情符号,以暗示您确实阅读了此文件。💖 是一个不错的起点,如果您不确定使用哪个表情符号。