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

Про автора

Діана Ільзе

початківчиня вебдизайнерка

Збираю портфоліо й вчуся пояснювати рішення не лише словами «мені так красивіше». Аналізую реальні сайти й записую, що саме заважає пройти сценарій до кінця.

Усі публікації автора