0

我正在使用项目引用和增量构建来探索 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命令,并且只在最顶层的应用程序的 package.json 中定义。(这个想法是在子项目中使用替代方案或其他任何东西,以防我真的想重建其中一个,并且出于某种原因只重建它的依赖项。)由于批量命令的性质,Rush 发出有关跳过的构建和缺少可能误导开发人员的脚本。此外,我不相信所有项目都在编译 - 例如,我没有看到生成的 js 文件 - 也许这是一个不相关的问题。ignoreMissingScript"build": "./node_modules/.bin/tsc -b ."build-me

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

4

1 回答 1

0

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

目前,两者不直接互操作。

如果您运行 Rush 增量构建命令(如 OOB rush build 命令),Rush 将重建具有非 .gitignored 文件的项目,这些文件的哈希值自上次运行命令以来已更改。

Heft 的增量 TypeScript 构建仅重建自上次运行 heft 构建以来未更改的单个 TS 文件。如果在运行项目的 heft 构建命令之前没有运行 heft clean --clear-cache,那么如果项目的 Heft 构建缓存文件夹 (/.heft/build-cache) 中存在有效的增量状态,则构建将是增量的。无论您是否运行增量 Rush 构建命令,都会发生这种情况。

那有意义吗?

于 2020-11-23T23:43:19.520 回答