ts-rust: экспериментальный перенос компилятора TypeScript 7 на Rust

7 октября 2026 года на Hacker News появился материал о ts-rust — экспериментальном переносе компилятора TypeScript на Rust. Как следует из описания проекта, автор с помощью языковых моделей перенёс компилятор, проверку типов и языковой сервер из нативной реализации Microsoft на Go. Выпуск ранний: команде, которой интересна скорость проверки типов, стоит пробовать порт на своём проекте и сверять результаты с соответствующей версией компилятора на Go, а не сразу заменять рабочий инструмент.

Что перенесли и с чем сравнивают

ts-rust, также называемый tsc-rs, воспроизводит алгоритмы и поведение реализации на Go. У него те же параметры командной строки, а также языковой сервер и API. Пакет опубликован в npm под именем tsc-rs, чтобы не конфликтовать с пакетом typescript. Для поддерживаемых платформ есть и архивы с исполняемым файлом и необходимыми библиотеками.

Порт закреплён на ревизии от 29 сентября 2026 года — TypeScript 7.1.0-dev. Это важно при разборе ошибок: сравнивать его предлагают с реализацией на Go той же ревизии, а не с TypeScript 7.0.x. Если tsc-rs сообщает об ошибке, которой нет в 7.0.2, причина может быть в изменившейся проверке TypeScript, а не в самом переносе.

Автор сообщает, что все 181 711 перенесённых тестов Go проходят. На тестовых наборах ответы языкового сервера и API совпадают с версией на Go. В 120 открытых репозиториях вывод командной строки, по данным проекта, различается лишь в перечисленных проблемных случаях и там, где результат самой Go-версии меняется от запуска к запуску. Это широкая проверка совместимости, но не гарантия для любого приложения.

В измерениях на шести открытых приложениях среднее геометрическое ускорение относительно tsc 6 составило 11,4 раза для tsc-rs и 7,1 раза для tsc 7 на Go. По сравнению с Go-версией порт оказался быстрее в 1,61 раза. Проверка VS Code заняла 4,20 секунды против 6,84 секунды у tsc 7. При этом bun check справился за 1,62 секунды, хотя на двух приложениях сообщил об ошибках, которых другие инструменты не нашли. Замеры проводились на Apple M4 Pro: для каждого результата взяли медиану пяти запусков после одного прогрева. На другой конфигурации разница может быть иной.

Где пока возможны расхождения

Проект предлагает установку через npm и запуск с tsconfig.json. Доступны Linux x64 и macOS arm64; сборок для Windows и Linux arm64 пока нет, сроки их появления не указаны. В репозитории есть сборка для WebAssembly, а производительная проверка типов в WASM названа одной из целей. Данных, позволяющих оценить её скорость в приведённых сравнениях приложений, нет.

В некоторых монорепозиториях исходники пакета доступны и через node_modules, и через прямой импорт. В таком случае tsc-rs может создать выходные файлы для большего числа исходников пакета и сообщить об ошибке TS6059. Есть и другая проблема: при сборке нескольких проектов без явно заданной ссылки на зависимый проект компилятор может прочитать его старые или отсутствующие выходные файлы. Для этого случая автор предлагает добавить ссылку на проект. Во время длительной работы в редакторе память тоже постепенно растёт — примерно на 20 МиБ за 1000 правок в проведённых измерениях.

Для проектов на Effect в tsc-rs встроены диагностики: они включаются, если соответствующий плагин указан в tsconfig. Поэтому для получения этих сообщений не нужен второй проход проверки. Но возможности языкового сервиса Effect для редактора, включая быстрые исправления, рефакторинг, подсказки при наведении и автодополнение, не перенесены. Совпадение диагностик не означает совпадения всего опыта работы в редакторе.

Что это значит для команды проекта

Команде, отвечающей за проверку типов и сборку, имеет смысл следить за ts-rust, если длительность проверки мешает работе. Но таблицы скоростей недостаточно для решения о замене: порт сравнивают с определённой ревизией TypeScript, а проект может зависеть от других настроек и сценариев сборки. Даже для опубликованного сравнения четырём приложениям потребовались изменения, чтобы проверка на tsc 7 завершалась без ошибок.

Разумная проверка — запустить tsc-rs на собственной конфигурации, сопоставить диагностики с TypeScript 7.1.0-dev соответствующей ревизии на Go и отдельно проверить сборку и работу в редакторе. Если проект использует монорепозиторий, ссылки между проектами или Effect, перечисленные ограничения особенно важно проверить до обсуждения перехода. Пока результат бенчмарка показывает повод для эксперимента, а не готовность к замене компилятора в рабочем процессе.

Моё мнение: скорость требует проверки

Я бы не принимала заявленную совместимость за готовое обоснование перехода. Автор прямо пишет, что не читал написанный код, и одновременно перечисляет проблемы, которые способны проявиться не в тестовой таблице, а в конкретной сборке. Для меня это не причина отвергать проект. Скорее, причина спросить, какие результаты команда сможет воспроизвести сама и что именно сочтёт допустимым расхождением.

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

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. ts-rust: An experimental Rust port of the TypeScript 7 compiler (tsc) github.com

Об авторе

Диана Ильзе

начинающий веб-дизайнер

Собираю портфолио и учусь объяснять решения не только словами «мне так красивее». Разбираю реальные сайты и записываю, что именно мешает пройти сценарий до конца.

Все публикации автора