跳至主要内容

问题

本文档作为您管理我们 GitHub 问题 的指南，也称为问题分类。

在对问题进行分类时，请运用你的最佳判断，最重要的是，请记住在回复用户时要鼓励、友好和善良。许多用户是第一次接触开源和/或类型检查。我们必须为他们提供积极、鼓舞人心的体验。

提示

如果你对问题管理的任何部分有任何疑问，请随时联系拥有更多上下文信息的维护者寻求帮助！

治理​

根据贡献者层级 > 指标中的标准

  • 简单问题：由审阅者自行决定，任何提交者或维护者都可以标记为已批准。这包括文档增强、错误修复和功能添加。
  • 非简单问题：需要两个提交者批准或一个维护者批准才能标记为已批准。这包括重大的内部重构和非破坏性的公共 API 更改。
  • “不寻常”类别：需要公开讨论，然后由两位维护者批准。这包括对跨项目和公共 API 产生影响的重大重构。

问题流程​

注意

我们在.github/replies.yml中提供了一组对问题的常见回复，这些回复旨在与Refined Saved Replies扩展一起使用。不要将这些视为你必须使用的确切回复：它们只是一个开始的复制粘贴助手。请根据你的个人语气和非简单问题的线程，调整你的特定回复。

待处理问题 可以使用 triage 标签进行搜索。该标签在创建新问题时会自动添加。大多数问题在创建或更新时会经过以下审查流程。

  1. 维护人员确保问题有效
    • 如果发布者没有填写包含足够信息的适当模板
      • 添加 please fill out the template 和 awaiting response 标签，并删除 triage 标签
      • 使用需要更多信息的回复向发布者索取更多信息
    • 如果它是已存在问题的重复
      • 添加 duplicate 标签并删除 triage 标签
      • 如果它是明显的重复问题，请发布明显重复问题的回复，并链接到现有问题
      • 如果不是明显的重复问题，请链接到现有问题并解释原因
      • 将问题关闭为未计划
    • 如果代码按预期工作
    • 如果问题包含在 typescript-eslint 方面不太可能实现的类似增强功能的请求
    • 如果问题需要进一步讨论或社区参与评估
      • 添加 evaluating community engagement 标签并删除 triage 标签
  2. 如果报告有效，请添加 accepting prs 标签并删除 triage 标签
  3. 如果您知道修复的大致步骤，请考虑编写包含代码库链接的评论，以帮助某人完成修复
  4. 如果您认为修复相对简单，请考虑添加 good first issue 标签

每当问题等待报告者提供更多信息时，都应添加 awaiting response 标签。当提供更多信息时

  • 如果你有时间再次查看分类流程，请这样做。
  • 如果你没有时间，请添加 triage 标签并移除 awaiting response 标签。
提示

如果你的链接既是“永久链接”（包含提交哈希而不是分支名称）又包含行号/行范围，那么 GitHub 会将代码嵌入你的评论中。在 GitHub 中查看文件时，按 y 键会将 URL 更新为包含当前提交哈希的“永久链接”，然后你可以选择相关行并将该 URL 粘贴到评论中。

寻找重复项​

值得注意的是，有时用户会故意提出重复问题，因为他们认为原始问题在不应该关闭的情况下被关闭了。如果是这种情况，你应该阅读原始问题以收集上下文，了解其被关闭的原因，并确定新问题是否提出了需要解决的任何新的或相关的点。

确定代码是否按预期工作​

随着你对代码库和工作原理的熟悉，这将更容易直观地完成，但一开始，这可能需要调查文档、代码和测试以确定它是一个 bug 还是按预期工作。一般来说，如果有一个通过的测试或与重现代码相同或类似的文档示例，则表明它按预期工作。如果你找不到任何匹配的内容，请根据代码的精神做出最好的判断。

社区参与评估​

在大多数情况下，维护者对人们如何编写代码以及 typescript-eslint 工具的大多数用户想要什么有很好的了解。但是，在某些情况下，维护者无法自信地选择解决特定问题的最合理方法。

  • 问题主题与维护者不熟悉的库/框架相关。因此，他们不知道与之相关的惯用模式。
  • 存在新的语法或新功能 - 有时很难猜测人们如何使用该功能。
  • 这个问题原本要关闭了，但有人提出了有力的论据。这需要进一步讨论，以找到大多数人同意的观点。

在问题被标记为评估社区参与后的 3-6 个月内，会评估社区的参与度。

  • 如果社区活跃且找到了共同点，则将问题标记为接受 PR。
  • 否则，问题将以未计划关闭，并标记为wontfix。

对于可以在 typescript-eslint 之外实现的请求，请务必提及任何相关的 API，例如可以使用的自定义规则。

跳过步骤​

随着你对代码库和其预期行为越来越熟悉，你将能够根据需要跳过步骤或按顺序执行操作。例如，你可能能够识别出错误报告是“按预期工作”的，或者你可能识别出问题是重复的，而无需填写完整的 issue。在这种情况下，你可以省略来回讨论，直接跳到关闭步骤。

特定问题类型​

🐛 错误报告​

🐞 “简单”错误​

简单错误是指可以在单个 TS 文件加上 ESLint 配置（可能还有 TSConfig）中重现的错误 - 也就是说，可以在我们的 playground上重现的问题。绝大多数错误报告都属于此类。

如果你无法使用 issue 提供的 playground 重现描述中的问题，则说明它没有提供足够的信息。请考虑使用特定的回复，例如需要 Playground 重现回复。

🦟 “复杂”错误​

复杂错误是指需要多个文件才能重现的错误。这种情况比较少见，但当人们使用库类型或类型导入时出现问题时会发生。

这些错误应与指向 GitHub 存储库的链接一起报告，该存储库可以签出以重现问题。如果你无法使用存储库的 README.md 和 issue 描述重现描述中的问题，则说明它没有提供足够的信息。请考虑使用特定的回复，例如需要完整重现回复。

🏗 功能请求​

对于任何功能请求，请确保所请求的支持符合以下条件：

  • 对于至少一种常用的 TypeScript 运行方式非常有用（例如 tsc 构建的 CLI 包；捆绑器管理的 Web 应用程序）
  • 与大多数使用 typescript-eslint 的项目相关

我们避免以下功能：

  • 仅与少数用户相关，因为它们可能不值得维护负担
  • 不是 TypeScript 特定的（例如，应该在 ESLint 核心而不是这里）
  • 仅与特定用户端框架或库相关，例如 Jest 或 React
  • 用于“格式化”功能（我们强烈建议用户使用单独的专用格式化程序）

✨ 规则增强​

我们通常接受符合上述功能请求标准的规则增强。如果规则增强会实质性地改变规则的目标区域，请考虑它是否应该是一个新的规则。这方面的常见迹象是规则的原始名称现在不准确，或者某些选项仅与旧功能相关。

可能导致报告新问题的增强被视为重大更改。我们有两个常见的策略来处理它们

  • 将增强视为重大更改，并在下一个主要版本之前阻止合并它
  • 添加一个选项来禁用新逻辑：如果选择加入，则这是一个重大更改，如果选择退出，则不是重大更改
  • 添加一个选项来启用新逻辑：如果选择退出，则这是一个重大更改，如果选择加入，则不是重大更改

有关命名选项的上下文，请参阅 我们可以标准化规则选项的逻辑方向吗？。

对于旨在限制规则目标节点类型的增强，请将问题标记为在 RFC：指定类型或值作为规则选项的通用格式 上被阻止。

🚀 新规则​

我们通常接受符合上述功能请求标准的新规则。最大的例外是那些可以使用 @typescript-eslint/ban-types 和/或 no-restricted-syntax 大致实现的规则。

修剪旧问题​

我们喜欢定期搜索等待回复的开放问题，以找到可能被遗忘的问题。对于等待超过 1 个月的問題，我们的流程是

  1. 使用类似于正在检查模板的消息ping作者
  2. 在问题中添加stale标签
  3. 等待 2 周
  4. 如果他们仍然没有回复，请使用类似于修剪陈旧问题模板的消息关闭问题