`rush build` 和 `tsc -b` 一起玩好吗？

Question

我正在使用项目引用和增量构建来探索 Rush/PNPM 和 Typescript，但我有点困惑这两者中哪一个最适合管理增量构建。

如果我使用内置命令 rush build 进行增量构建，我认为 Rush 正确地识别出所有已知项目的 package.json 声明中的依赖关系，并以依赖关系运行它们每个的 build 脚本命令。如果每个 typescript 项目的 build 脚本是 ./node_modules/.bin/tsc -b .，那么树上的每个依赖都将按照依赖顺序构建。

其中，tsc 还将根据其 references paths 列表评估 package.json 依赖项。理想情况下，它会（？）认识到其依赖项的早期独立构建使它们成为最新的并且不需要重新构建，然后仅构建直接项目的代码作为其rush build调用构建的一部分。如果这甚至是可靠和稳定的，那么它似乎充其量是不必要的依赖树评估，对吧？

我尝试在 command-line.json 中将 rush 的 build bulk 命令覆盖为 ignoreMissingScript，并且只在最顶层应用程序的 package.json 中定义 "build": "./node_modules/.bin/tsc -b ."。 （想法是在子项目中使用替代build-me 或其他任何东西，以防我真的只想重建其中一个，并且出于某种原因只重建它的依赖项。）由于批量命令的性质，Rush 发出关于跳过的构建和丢失的脚本可能会误导开发人员。此外，我不相信所有项目都在编译 - 例如，我没有看到生成的 js 文件 - 也许这是一个不相关的问题。

我没有看到任何简单的 Rush 配置来推迟打字稿 - 我们不允许将 build 命令行覆盖为 global 样式的 shell 命令。我觉得我真的只希望 Rush 用于包管理而不是脚本运行（因为它太受限制了）。而且，我不能轻易地阻止rush build 支持运行主项目的打字稿增量构建的其他方式。我很惊讶没有找到任何相关的搜索结果，因为这两个都是尖端的 Microsoft 项目。我错过了一些基本的东西吗？

Answer 1

来自https://github.com/microsoft/rushstack/issues/2368

目前两者不直接互操作。

如果您运行 Rush 增量构建命令（如 OOB rush build 命令），Rush 将重建包含不包含文件的项目 .gitignored 自上次命令以来其哈希已更改 已运行。

Heft 的增量 TypeScript 构建仅重建单个 TS 文件 自上次运行 heft build 以来，这一点没有改变。如果你 在运行项目的重量之前不要运行 heft clean --clear-cache build 命令，如果有效，则构建将是增量的 增量状态存在于项目的 Heft 构建缓存文件夹中 (/.heft/build-cache)。这将发生，无论 无论您是否运行增量 Rush 构建命令。

这有意义吗？