`Rush build` и` tsc -b` хорошо сочетаются друг с другом?

Question

Я изучаю Rush/PNPM и Typescript со ссылками на проекты и инкрементными сборками, но меня немного смущает, какая из двух лучше всего подходит для управления инкрементными сборками.

Если я использую встроенную команду для rush build инкрементная сборка, я думаю, что Rush правильно распознает зависимости среди всех известных проектов объявлений package.json и запускает buildскрипт каждого из них в порядке зависимости. Если каждый проект машинописного текста build сценарий ./node_modules/.bin/tsc -b . тогда каждая зависимость по дереву будет построена в порядке зависимостей.

В нем tsc также будет оценивать зависимости package.json от его references pathсписок s. В идеале он (?) Распознает, что более ранние независимые сборки его зависимостей делают их текущими и не нуждаются в перестройке, а затем только строят код для непосредственного проекта как часть его rush buildвызвал build. Если это даже надежно и стабильно, это в лучшем случае кажется ненужным количеством оценок дерева зависимостей, верно?

Я экспериментировал с подавляющим порывом build bulk приказать ignoreMissingScript в command-line.json и определить только "build": "./node_modules/.bin/tsc -b ."в самом верхнем приложении package.json. (Идея состоит в том, чтобы использовать альтернативный build-meили что-то еще в подпроектах на тот случай, если я действительно хочу просто перестроить один из них и только его зависимости по какой-то причине.) Из-за характера групповых команд Rush выдает сообщения о пропущенных сборках и пропущенных скриптах, которые могут вводить в заблуждение разработчик. Кроме того, я не уверен, что все проекты компилируются - например, я не вижу результирующих файлов js - возможно, это не связанная с этим проблема.

Я не вижу простой конфигурации Rush для откладывания на машинописный текст - нам не разрешено переопределять build командная строка, чтобы быть global-style команда оболочки. Я чувствую, что на самом деле мне нужен Rush только для управления пакетами, а не для запуска скриптов (поскольку он слишком ограничен). Но также я не могу легко отговорить rush buildв пользу другого способа выполнения инкрементальной сборки машинописного текста основного проекта. Я удивлен, что не нахожу никаких релевантных результатов поиска, поскольку это оба передовых проекта Microsoft. Я упустил что-то фундаментальное?

Answer 1

С https://github.com/microsoft/rushstack/issues/2368

Прямо сейчас эти двое напрямую не взаимодействуют.

Если вы запустите команду инкрементной сборки Rush (например, команду OOB rush build), Rush перестроит проекты, в которых есть файлы, не относящиеся к.gitignored, чьи хэши изменились с момента последнего запуска команды.

Инкрементальная сборка TypeScript от Heft восстанавливает только отдельные файлы TS, которые не изменились с момента последнего запуска сборки heft. Если вы не запустите heft clean --clear-cache перед запуском команды heft build проекта, то сборка будет инкрементальной, если в папке кэша сборки Heft (/.heft/build-cache) существует допустимое инкрементное состояние. Это произойдет независимо от того, запускаете ли вы команду инкрементальной сборки Rush или нет.

Имеет ли это смысл?