TypeScript ESLint 规则优化：允许 Promise.reject 抛出 any 和 unknown 类型错误

在 TypeScript 开发中，Promise.reject 方法的错误处理一直是一个值得关注的话题。typescript-eslint 项目中的 prefer-promise-reject-errors 规则旨在确保开发者只使用 Error 类型或其子类作为 Promise.reject 的参数，从而提高代码的健壮性和可维护性。

当前规则的限制

目前，prefer-promise-reject-errors 规则强制要求 Promise.reject 只能接受 Error 类型或其子类作为参数。这种严格的类型检查虽然有助于提高代码质量，但在某些实际开发场景中可能会显得过于严格。

特别是在使用 try-catch 块捕获错误时，TypeScript 4.4 引入的 unknown 类型捕获已经成为推荐做法。然而，当开发者需要将捕获的未知错误通过 Promise.reject 再次抛出时，当前的规则会报错，即使开发者已经正确地使用了 unknown 类型。

规则优化方案

为了解决这个问题，我们建议为 prefer-promise-reject-errors 规则添加两个新选项：

1. allowThrowingAny - 允许使用 any 类型作为 Promise.reject 的参数
2. allowThrowingUnknown - 允许使用 unknown 类型作为 Promise.reject 的参数

这种设计与同项目中的 only-throw-error 规则保持了一致性，为开发者提供了更灵活的错误处理选择。

实际应用示例

优化后的规则将允许以下代码模式：

async function handleError() {
  try {
    // 可能抛出错误的操作
  } catch (error: unknown) {
    // 当启用 allowThrowingUnknown 选项时
    return Promise.reject(error); // 不再报错
  }
}

类型安全考量

虽然放宽了类型限制，但这种优化仍然保持了 TypeScript 的类型安全优势：

1. 对于 unknown 类型，开发者在使用前仍然需要进行类型检查或断言
2. 这些选项默认是关闭的，需要开发者显式启用
3. 与 any 相比，unknown 类型提供了更好的类型安全性

最佳实践建议

在实际项目中，我们建议：

1. 优先使用 unknown 而非 any，即使两者都被允许
2. 在 reject 之前，尽可能对 unknown 错误进行类型细化
3. 在团队规范中明确何时使用这些宽松选项

总结

这次规则优化在保持代码质量的同时，增加了对现代 TypeScript 错误处理模式的支持。它特别适合那些已经采用 unknown 类型进行错误捕获的项目，使类型系统与实际开发需求更加契合。对于注重类型安全又需要灵活性的团队，这无疑是一个值得期待的改进。