检索词
- 类型覆盖率
- 流动覆盖率
建议
如果TypeScript有一个工具来捕获类型覆盖度量，我会很高兴，类似于Flow的Type Coverage特性。IDE（同样，目前Flow支持）可以使用该覆盖数据来突出类型覆盖中的差距。基本上，它应该告诉我们代码的哪些部分被评估为any。
假设它像Flow的特性一样工作，这可能是一个单独的tsc选项或单独的cli命令。它们只对单个文件工作，还提供了一个batch-coverage命令来检查目录/整个项目等。
用例
- Type Coverage度量可以像测试覆盖信息一样使用，帮助我们识别类型中的差距（特别是由于库代码中的类型定义不足而导致的意外差距）。
示例
检查清单
我的建议符合以下准则：
- 这不会是对现有TypeScript/JavaScript代码的重大更改
- 这不会改变现有JavaScript代码的运行时行为
- 这可以在不基于表达式的类型发出不同JS的情况下实现
- 这不是运行时功能（例如，库功能、带有JavaScript输出的非ECMAScript语法等）
- 这个特性将与TypeScript's Design Goals的其余部分一致。
5条答案
按热度按时间ql3eal8s1#
嗨，@RyanCavanaugh，谢谢你的回复。
这可能不是详尽的，但就我的目的而言，“未覆盖”可能意味着代码（可能是标识符、函数参数或返回类型）被推断为
any。所以我不一定要寻找TS放弃的情况，而是寻找那些我的代码由于某种原因而不是强类型的地方。我的动机是帮助我识别代码中我可能有错误安全感的地方，因为我可能认为所有东西都是强类型的，但实际上，
any已经找到了它的方法，可能是由于第三方类型等。q0qdq0h22#
拥有像https://github.com/plantain-00/type-coverage这样的原生功能将是超级棒的。
我在所有的TS / JSDoc项目中都使用了
typescript和type-coverage。bwitn5fc3#
请参阅https://github.com/codechecks/typecov
xdnvmnnf4#
@dsherret，typecov / type-coverage是通过compose处理函数组合，还是
lodash.flow/lodash/fp.pipe？在这些场景中，我经常发现传递给下一个函数的一个或多个结果实际上是
any。我记得我试过
type-coverage，发现它似乎只跟踪显式标识符，而不是像这样的隐式类型。xzabzqsa5#
对“未覆盖”的具体定义将是一个很好的起点。当TS出于任何原因需要给予分析的某个部分时，它将发出错误，而流有时将静默地这样做。