TypeScript 5.8 и тормоза tsc на большом проекте, как лечите

[maitee92]

tsc на нашем монорепо проверяет типы 2 минуты 40 секунд и это уже невыносимо, ищу как реально ускорить, а не как смириться. Проект большой, ~4500 файлов, куча дженериков, zod схемы везде, tRPC. tsc --noEmit на CI стал бутылочным горлышком, локально watch режим прогревается долго и жрет 6 гигов памяти.

Что уже сделал: включил incremental, разбил на project references (штук 12 пакетов), skipLibCheck стоит. Помогло, было 4+ минуты, стало 2:40, но хочется в район минуты. tsgo (нативный компилятор на go от майков) пробовал на бете, он реально быстрее раза в три на проверке, но падает на части наших типов и плагины не подхватывает, в прод его пока страшно.

Главный убийца у нас, судя по --generateTrace и анализу в analyze-trace, это пара мест с глубокой условной типизацией в дженериках и здоровенные union из zod infer. Вопрос к тем кто проходил: что дало максимальный выигрыш по времени реально, а не на бумаге?

[matguyvr]

tsgo же еще в превью, на нем в проде сидеть рано, но как тренд правильно что туда смотришь. через год это будет дефолт и весь этот танец с references забудется как страшный сон

по текущему: первым делом ищи типы которые резолвятся в гигантские union. zod infer на схеме с 40 полями где половина union это ад для чекера. иногда дешевле руками описать тип чем выводить

[alla_mihailova]

здоровенные union из zod infer

вот тут собака порылась. у нас был ровно этот кейс, дискриминированный union из 30 вариантов через z.discriminatedUnion и каждый еще вложенный. tsc на этом файле сидел секунд 20 один.

что помогло конкретно: вынесли тяжелые схемы в отдельный package с project reference, чтобы он билдился раз и кешировался в .tsbuildinfo, а не перепроверялся при каждом изменении в апп коде. плюс там где z.infer давал монструозный тип, явно аннотировали публичные функции возвращаемым типом, чтобы чекер не разворачивал инференс наружу. суммарно минус 40% времени на холодном прогоне. trace до и после прям видно.

[torchchan]

skipLibCheck включи говорили они. он у тебя и так стоит, читай ОП внимательнее

[kungsan]

@torchchan, 6 гигов памяти это уже звоночек что где-то рекурсивный тип раздувается. поставь TIMING переменную и смотри check time по файлам. обычно 3-4 файла дают 70% времени и их точечно лечишь, а не весь проект оптимизируешь

[jpearce]

@автор а ты type-aware линтинг отдельно гоняешь? если eslint с typed rules еще сверху, то у тебя по сути дважды граф типов строится. мы вынесли tsc --noEmit и typecheck в разные джобы CI параллельно, и typed eslint правила порезали до самых нужных, время пайплайна упало хотя сам tsc не трогали

[raspberryops]

через год это будет дефолт и весь этот танец с references забудется

не забудется. references это не только про скорость, это про границы пакетов и инкрементальность билда в монорепе. tsgo ускорит проверку но архитектурно references все равно нужны если ты не хочешь чтобы один пакет тянул пересборку всего. так что это не костыль на время

[k8s2000]

минута на 4500 файлов это нормально вообще то, чего ты хочешь. у нас 9к файлов и 5 минут, и ничего, живем. на CI закешировали .tsbuildinfo между ранами и инкремент добивает за 40 сек если мало менялось. полную проверку гоняем только на мерж в мейн