嗯，这不应该发生。运行测试任务依赖于dts任务。我故意留下的唯一“漏洞”是当你在vscode中使用启动任务时，因为它直接运行测试套件，我认为这是“可以接受的”，因为这应该是快速的，而且这种方式运行单元测试本身就不太对。在命令行界面上，它应该是准确的。

你是否与--no-typecheck一起运行？如果是，它将跳过dts发射。

哦，是的，我就是😅

关于dts在runtests通过时是否是依赖项，我可以采取两种方式；它们似乎都有各自的优缺点。完全愿意将其更改为最不令人惊讶的内容，我只是选择了“如果你说--no-typecheck,它永远不会进行类型检查”。但是，显然我们需要这样的信息，例如测试。

感觉API基线测试与其作为常规测试包含在测试套件中的意义不如以前那么大。由于它具有不同的依赖关系，感觉更干净的长期解决方案是将其作为一个单独的任务/检查。

我同意。在模块转换中，我没有采用这种方法，因为我试图尽量减少更改，但主要是因为我不确定如何添加这样的测试。打包器是一个脚本，而不是src中的某个东西，所以我不太确定如何组织它，何时运行等。

我想我们的测试已经依赖于从scripts导入某些内容(failed-tests.cjs),所以让它运行打包器并比较输出或类似的东西并不是不可能的。

鉴于bundler不是自包含的，需要构建系统运行以生成输入的d.ts文件，我更倾向于让runtests始终依赖于dts,无论是否提供了--no-typecheck,并保持这个作为单元测试的状态。至少，这将完成可能的最小类型检查(仅对typescript.d.ts和tsserverlibrary.d.ts需要),对我来说似乎可以接受。但是，我不确定我们想在哪里划定界限；现实是这些测试将不得不在某个地方进行类型检查，我不知道是否想让测试工具能够运行hereby ...