TypeScript Design Meeting Notes, 6/18/2024
覆盖率报告
#58850
- C8
- 覆盖系统,封装了Node.js使用的JS引擎V8。
- 我们目前有一个类似这样的任务,可以运行
npm tests -- --no-lint --coverage
。 - 问题:当你将我们的整个代码库与esbuild捆绑在一起时,文件会变得非常大。C8的内置工具在处理TypeScript的覆盖率报告方面效果不佳。
- Monocart:一个不仅可以预览整个生成的文件,还可以处理sourcemaps并给出分支是否命中的详细信息的预览工具。
- 还具有输出模式,用于codecov,这是一个跟踪代码测试覆盖的服务。
- 可能不希望有评论说“你的覆盖率下降了!”并且阻止合并,但我们确实需要覆盖率报告。
- 缺点:它使CI运行速度变慢(加倍!)。
- 很想知道“哪些测试依赖于执行给定分支?”
- VS Code可能正在使用API: Attributable Test Coverage vscode#212196探索这个问题。
- 为什么我们在不想实际使其可见的情况下还要这样做?
- 好问题。
- 我们对检查器的覆盖率超过97%,但许多未触及的分支。
- 我们想在将其纳入CI之前等待提高运行速度的方法 - 但首先让我们为本地添加一个可选的对等依赖项,以便人们可以运行它。
Knip
#56817
- 一个实用程序,用于标记不在文件外部使用的函数,删除未使用的文件,以及删除既未作为公共API的一部分导出又未使用的实用程序。
- 通过在前一个注解中添加一个
/** @knipignore */
标签来做出例外。 - 上次我们谈论这个时,不是安装时间延迟吗?
- 是的,但从那以后Knip已经减少了其依赖树。
- 那运行时间呢?
- 大约7秒 - 不错。
- 我们正在考虑只在CI中进行。
@internal
标签
- 基本上是一种正式编码
--stripInternal
应该做什么的方式,并表示它仅适用于JSDoc注解。 - 使您能够编写
// Do not add an @internal tag to the next declaration
,因为TypeScript现在将认为这无关紧要。 - 用
--stripInternal
,我们一直说“它有bugs,嗯,可争议的行为。” - 这是使其更正式的一种方式 - 或者至少更可预测。
- 这是否会增加开销,因为我们现在开始要求在emit中也有JSDoc注解?
Core Utilities中更多的“原始”操作
#58873
- 从一开始就有一条跟踪记录,其中内部
some
函数只是一个大的热点路径。 - 许多操作隐式地执行的工作比您可能预期的要多得多,但有相当不错的替代方案。
||
检查真值,但 ??
只检查 null
/ undefined
。- 对
undefined
的显式检查比真值快。 for
- of
循环创建迭代器,但 for (let i = 0; i < arr.length; i++)
不会。- PR进行了一些更改,主要集中在避免产生太多噪音的
core.ts
上。 - 不幸的是,这里没有免费的午餐。抽象化是有明确代价的。
回答(1) 发布于 5个月前
回答(3) 发布于 5个月前
回答(3) 发布于 6个月前
回答(1) 发布于 5个月前
回答(1) 发布于 6个月前
2条答案
按热度按时间p4rjhz4m1#
for-of
创建迭代器,但for (let i = 0; i < arr.length; i++)
不会。在这一点上,我本以为
for (const foo of foos) {}
会被引擎高度优化。因为数组的迭代器实际上并没有 真正 做任何事情,所以如果大多数引擎没有在这个情况下优化掉它,我会感到惊讶。bsxbgnwa2#
我原本以为
for (const foo of foos) {}
在这个点已经被引擎高度优化了。由于数组迭代器实际上并没有做任何事情,如果大多数引擎没有在这个情况下优化掉它,我会感到惊讶。然而,for-of循环仍然经常比for循环慢很多倍,例如在v8中,这个差异有10倍,而在jsc中有4倍(有趣的是,内联forOfLoop函数也使v8的差异达到了4倍):