TypeScript 7 (tsgo): прогнал на нашей монорепе — тайпчек с 4 минут до 19 секунд. Но не всё гладко

[envoycoder]

На выходных наконец дорвался до tsgo — нативного компилятора TypeScript на Go, который Майкрософт двигает как будущий TypeScript 7. Поставил @typescript/native-preview и прогнал на рабочей монорепе: 14 пакетов, около 280 тысяч строк, strict-режим.

Цифры такие. Полный тайпчек: tsc 5.9 — 3 мин 52 сек, tsgo — 19 секунд. Память: было 6+ гигов (в своё время пришлось специально раннер на CI раскармливать), стало около 1.2. Холодный старт language server в VS Code — секунды две вместо привычной полуминуты, go to definition мгновенный даже в самых жирных файлах с generics.

Теперь ложка дёгтя:
— ts-patch и кастомные трансформеры не работают и не заработают, это официальная позиция команды;
— пара наших фокусов с declaration merging дала расхождения в выводе типов. Одно оказалось багом превью, второе — багом старого tsc, лол;
— typescript-eslint в режиме projectService пока гоняет типы через старый компилятор, так что линт остался медленным.

В CI поставил двойную схему: tsgo на каждый пуш, классический tsc — ночным прогоном для сверки. Две недели — расхождений ноль. Кто ещё гонял на больших проектах?

[lteng1]

Превью-компилятор блокирующим чеком на каждый пуш — смело. Мы после похожего энтузиазма однажды месяц жили с зелёным CI и сюрпризами на проде. Ночная сверка — это хорошо, но день расхождения — это день, за который в мейн уехало неизвестно что. Я бы наоборот: tsc блокирующий, tsgo советательный, пока не объявят stable.

[misha12]

@envoycoder, Поясню, откуда берётся такая разница, а то «в 10 раз быстрее» звучит как магия. Во-первых, Go компилируется в натив — нет прогрева JIT, который у tsc на ноде съедал первые секунды любого запуска. Во-вторых, настоящая многопоточность: парсинг и чек раскидываются по ядрам, а в JS-версии всё упиралось в один поток, воркеры с изоляцией памяти там толком не взлетели. В-третьих, структуры вместо объектов — меньше давления на сборщик.

Важное следствие, о котором мало говорят: старое compiler API целиком не переносят. Вместо него будет новый API поверх межпроцессного протокола, поэтому всё, что лезло руками во внутренности tsc — ts-patch, трансформеры, добрая половина language service плагинов — мертво по дизайну, а не по недосмотру. Кто на этом строил кодогенерацию — закладывайте переезд заранее.

По схеме согласен с автором, а не с комментарием выше: блокирующим имеет смысл держать быстрый инструмент, иначе никто не будет ждать четыре минуты перед пушем, и проверки начнут скипать. Расхождения между движками сейчас единичные, команда их чинит приоритетом — у них цель байт-в-байт совместимый вывод типов.

[react_fan]

А у нас транспиляция давно через esbuild внутри Vite, тайпчек только в CI — и перф tsc как бы не болел. Но вот эдитор — да. В монорепе на Nx у меня tsserver стабильно отъедает 4 гига и думает по 8-10 секунд после переключения ветки. Ради одного только language server уже стоит переходить, остальное бонусом.

[sergeyserov]

На чём гоняли, если не секрет? Спрашиваю, потому что tsgo очень любит ядра. Дома на M3 Pro у меня вышло х13, а на гитлаб-раннере с двумя vCPU на дешёвом тарифе Selectel — скромные х4. Так что «в десять раз быстрее» из анонсов — это про многоядерные машины, на нищих раннерах чудес поменьше. Хотя х4 тоже никто не вернёт.

[kotlinmaster]

Апдейт спустя неделю, отвечаю заодно на вопрос: локально Ryzen 9, на CI 8 vCPU, там вышло х9. Погонял watch-режим: пересборка после правки 0.3-0.5 сек, причём стабильно, без рандомных фризов как у tsc --watch. Последнее узкое место теперь линт — смотрим на oxlint с тайп-правилами, чтобы добить и его. Моё пророчество: к концу года tsc 5.x в новых проектах станет таким же легаси, как webpack в мире сборщиков. Запомните этот пост.