TypeScript 6.0: последний компилятор на JavaScript перед Go

TypeScript 6.0: последний компилятор на JavaScript

TypeScript 6.0 beta исторически значим не новыми возможностями языка, а тем, что он сигнализирует об инфраструктуре под ним. Это финальный релиз компилятора TypeScript, написанного на JavaScript и TypeScript - инструмента, лежащего в основе разработки с 2012 года. TypeScript 7.0, стабильный с января 2026 года после года превью начиная с мая 2025-го, работает на полностью нативной реализации на Go под названием Project Corsa. Сам язык - система типов TypeScript, синтаксис и совместимость с JavaScript - не изменился. Меняется только то, как происходит компиляция TypeScript: вместо Node.js теперь нативный бинарник.

Промежуточный репозиторий нативного компилятора, microsoft/typescript-go на GitHub, открыт публично и в конечном счёте будет влит в основной репозиторий microsoft/TypeScript. Паритет по проверке типов уже почти достигнут: по данным обновления прогресса Microsoft за декабрь 2025 года, из 20 000 тест-кейсов расхождений осталось всего 74.

Изменения настроек по умолчанию, которые сломают вашу сборку

TypeScript 6.0 выходит с изменёнными значениями по умолчанию для пяти критических параметров tsconfig. Команды, обновляющиеся с 5.x без явной конфигурации, столкнутся с ошибками сборки - потенциально сотнями ошибок в зрелой кодовой базе.

Изменение types: [] застаёт команды врасплох чаще всего. Раньше TypeScript автоматически подключал все установленные пакеты @types/*. Теперь их нужно объявлять явно. Репозиторий, в котором никогда не указывался types, внезапно лишится всех ambient-объявлений типов. Рекомендуемый мост для команд, не готовых к полной миграции: добавьте "ignoreDeprecations": "6.0" в tsconfig, чтобы устаревшие параметры продолжали работать до готовности к TypeScript 7.0.

Новые возможности и что удаляется

TypeScript 6.0 добавляет поддержку ECMAScript 2025 и помечает как устаревший набор legacy-параметров, которые будут полностью удалены в TypeScript 7.0. Список устаревших параметров - более значимая для enterprise-команд со старыми пайплайнами часть, с операционной точки зрения.

Дополнения ECMAScript 2025

• Типы Temporal API: полная поддержка типов для Stage 4 предложения Temporal - современная замена объекту Date, доступна через -target esnext или "lib": ["esnext"]
• Map/WeakMap upsert: методы getOrInsert и getOrInsertComputed устраняют шаблонный код при работе с Map; доступны в lib esnext
• DOM iterables по умолчанию: содержимое lib.dom.iterable.d.ts теперь включено в lib.dom.d.ts - достаточно "lib": ["dom"]
• Subpath imports с #/: поддержка subpath imports Node.js для node20, nodenext, bundler
• Цель/lib es2025: RegExp.escape, обновлённые утилиты Promise и Iterator

Флаг -stableTypeOrdering

TypeScript 6.0 вводит диагностический флаг, специально предназначенный для команд, готовящихся к миграции на TypeScript 7.0. Флаг стабилизирует порядок типов в соответствии с детерминированным поведением параллельной архитектуры Go-компилятора. Используйте его для выявления расхождений до перехода на нативный компилятор; тот же тщательный подход к миграции практикуется при разработке сайтов красоты. Флаг может замедлить проверку типов до 25% - это инструмент миграционной диагностики, а не постоянная настройка конфигурации.

Параметры, которые удаляются в TypeScript 7.0

• target: es5 - минимальная цель теперь ES2015
• -moduleResolution node (node10) - перейдите на nodenext или bundler
• -module amd | umd | systemjs - перейдите на ESM
• -outFile - перейдите на esbuild, Vite или webpack
• -baseUrl без paths
• -esModuleInterop false и -allowSyntheticDefaultImports false (теперь всегда включены)
• -downlevelIteration - связан с ES5, больше не нужен

Почему Microsoft выбрала Go, а не Rust

Андерс Хейлсберг - создатель TypeScript, C# и Turbo Pascal - публично объяснил это решение в обсуждении в репозитории microsoft/typescript-go. Выбор определило конкретное инженерное ограничение: TypeScript компилятор активно использует разделяемую мутабельность и сборку мусора. Перенос на Rust потребовал бы переосмысления всей архитектуры памяти - это не перенос, а полная переработка. Сохранение 100 человеко-лет инвестиций в существующую архитектуру компилятора делало Go единственным практичным вариантом, как сообщал The New Stack в интервью с командой TypeScript.

Структурное сходство Go с существующей кодовой базой TypeScript позволило напрямую отобразить структуры данных. Ускорение в 10 раз достигается за счёт двух перемножающихся факторов: нативный бинарник ускоряет разработку сайтов примерно в 3-4x по сравнению с Node.js/V8, а горутины Go обеспечивают параллельный парсинг, привязку и проверку типов по независимым частям программы одновременно - ещё 2-3x. Такой параллелизм архитектурно невозможен в модели event loop Node.js - воркер-треды решают это лишь частично и требуют отдельной архитектуры для корректной реализации.

Компромиссы, которые приняла Microsoft

Сборщик мусора Go может давать редкие всплески производительности - модель памяти Rust обеспечила бы более предсказуемую латентность ценой полной переработки. Браузерный инструментарий, включая TypeScript playground и веб-редакторы, сложнее перенести на Go из-за размера WASM-бинарников. Это признанные компромиссы, а не упущения. Microsoft отдала приоритет скорости разработки и сохранению существующей архитектуры компилятора, а не теоретическому потолку характеристик Rust.

Ускорение в 10 раз: что показывают бенчмарки

Заголовок "10x" - не маркетинг. Это нижняя планка, а не потолок того, что Microsoft измерила на реальных производственных кодовых базах. VS Code (1,5 миллиона строк), Playwright (356 000 строк) и TypeORM (270 000 строк) - все показывают двузначные коэффициенты ускорения при компиляции нативным компилятором на Go, согласно официальным бенчмаркам Microsoft.

Улучшения языкового сервиса не менее значимы для опыта разработчика. Загрузка кодовой базы VS Code в языковой сервис сокращается с 9,6 секунды до 1,2 секунды - улучшение в 8 раз, которое напрямую выражается в более быстром IntelliSense, мгновенной обратной связи по ошибкам и более отзывчивом рефакторинге в любом редакторе. Потребление памяти - примерно вдвое меньше, чем у текущего компилятора, и команда Microsoft ещё не приступала к целевой оптимизации памяти. Эти цифры ещё улучшатся.

Команды с 15-минутными CI-сборками могут рассчитывать на экономию примерно 3 минут на каждый запуск при правильно настроенном TypeScript 6.0 - ещё до перехода на нативный компилятор. Явное указание types в tsconfig - одно из новых обязательных значений по умолчанию - устраняет лишнюю работу по разрешению типов и само по себе обеспечивает 20-50% ускорения сборки в протестированных проектах.

Go в enterprise: 18 000 компаний и чёткая закономерность

Go - не нишевый язык и не зарождающийся тренд. По состоянию на 2025 год свыше 18 000 компаний используют Go в продакшене, а 2,2 миллиона профессиональных разработчиков работают на нём как на основном языке - число, удвоившееся за пять лет. Ещё 11% разработчиков планируют начать использовать его в ближайшие 12 месяцев, по данным экосистемного отчёта JetBrains. Golang язык программирования занял прочные позиции в инфраструктуре, которую видят конечные пользователи ежедневно - будь то переводы денег, доставка еды или разработка кода в VS Code. Microsoft, выбрав Go для компилятора TypeScript, добавляет глобально используемый инструментарий разработчика к этому списку.

Цифры fintech заслуживают отдельного рассмотрения. Monzo обрабатывает 4 000 транзакций в секунду на пике нагрузки, при этом отдельные API обслуживают свыше 20 миллионов запросов в минуту. Торговые платформы на Go удерживают латентность ниже 20 миллисекунд при тысячах одновременных обновлений ордеров. Горутины потребляют всего несколько килобайт каждая, позволяя запускать миллионы конкурентных процессов без инфраструктурных накладных расходов. Эти характеристики - предсказуемая латентность, эффективная конкурентность, низкий расход памяти на соединение - не случайны. Они отражают архитектурные свойства, которые привлекли эти компании к Go.

Как мы работаем с Go в Webdelo

В Webdelo Go является нашим основным языком для fintech, интернет маркетинга и AI-интеграций уже несколько лет. Причины точно совпадают с тем, что Microsoft сформулировала при выборе Go для компилятора TypeScript: предсказуемая латентность под нагрузкой, горутины, масштабирующие конкурентность без накладных расходов пула потоков, и кодовая база, которую могут поддерживать инженеры, не писавшие исходный код. У нас были те же дискуссии о Go против альтернатив, что и у Microsoft - и мы пришли к тем же выводам по тем же причинам.

Вопрос, который мы чаще всего слышим от клиентов, понятен: "Мы работаем на Java 10 лет или на PHP 8 лет - и всё работает. Зачем меняться?" Ответ не "потому что Go современный" и не "потому что он быстрее". Ответ зависит от того, что строит клиент и что должно быть верно относительно его системы. Для fintech-сервиса, обрабатывающего платежи со строгими требованиями к латентности, или высоконагруженного API, где инфраструктурные затраты масштабируются с числом одновременных соединений, или систем продвижения в AI, которым нужно обрабатывать тысячи конкурентных webhook-событий - Go даёт измеримый ROI. Для legacy-монолита с глубокой интеграцией экосистемы Java правильный подход нередко - постепенная миграция по паттерну strangler fig: новые сервисы пишутся на Go, пока существующая система продолжает работать.

Что мы говорим клиентам, рассматривающим смену стека

• Начинайте с нового сервиса, а не с миграции: новый проект или изолированный сервис - правильная точка входа: никаких legacy-ограничений, чистые архитектурные решения
• Go читается проще, чем кажется: статическая типизация, явная обработка ошибок и прямолинейные примитивы конкурентности делают Go-код понятнее сопоставимого Java или PHP-кода при масштабировании
• Считайте TCO, а не только стоимость разработки: Go-сервисы стабильно требуют меньше инфраструктуры для эквивалентной нагрузки - меньше инстансов, меньше памяти на соединение, предсказуемое поведение при масштабировании
• Паттерн strangler fig работает: мигрировать всё сразу редко необходимо или разумно; сосуществование в переходный период - полноправный паттерн

Когда Go - не лучший выбор

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

• Браузерные и WASM-приложения: Go компилируется в тяжёлые WASM-бинарники - он не подходит для фронтенда. Именно поэтому Microsoft признала компромисс с WASM при выборе Go для компилятора TypeScript
• CPU-интенсивная работа без GC: если нужна детерминированная латентность без пауз сборки мусора - определённые системы торговли в реальном времени, встраиваемые контексты - Rust даёт более предсказуемое поведение
• Data science и ML-пайплайны: Python и R имеют более богатую экосистему библиотек для анализа данных и обучения моделей; Go не является значимым конкурентом здесь
• Команды без опыта Go: время онбординга реально и входит в расчёт TCO - если команда глубоко знает Java, а проект - стандартное enterprise-приложение без высоких требований к конкурентности, стоимость переключения может не окупиться
• Legacy-монолиты с тесной интеграцией фреймворков: иногда правильное инженерное решение - постепенное улучшение в рамках существующего стека, а не переписывание

Наша позиция: мы рекомендуем Go там, где он даёт измеримое преимущество для конкретной решаемой задачи - а не потому что это сейчас заметный тренд в индустрии.

Миграция на TypeScript 6.0: практический чеклист

Переход с TypeScript 5.x на 6.0 требует явной конфигурации параметров, которые раньше определялись автоматически. Самый быстрый способ оценить объём необходимых изменений в репозитории - диагностический прогон вхолостую с beta-версией.

Начните отсюда: быстрая диагностика

npm install -D typescript@beta
npx tsc -noEmit 2>&1 | head -50

Критические шаги миграции

1. Объявите "types" явно: добавьте "types": ["node"] или перечислите конкретные пакеты @types, используемые в проекте. Без этого новое значение по умолчанию [] вызовет 100+ ошибок из-за отсутствия ambient-объявлений типов
2. Задайте "rootDir": "./src" явно: автоматический вывод убран
3. Замените "moduleResolution": "node": перейдите на "nodenext" или "bundler"
4. Удалите "outFile": замените на esbuild, Vite или webpack в качестве бандлера
5. Обновите "target": замените "es5" на "es2015" или выше
6. Замените "module": "amd"/"umd"/"systemjs": перейдите на ESM
7. Запустите проверку совместимости с TS 7.0: npx tsc -stableTypeOrdering -noEmit и устраните расхождения до перехода на нативный компилятор
8. Используйте временный мост при необходимости: добавьте "ignoreDeprecations": "6.0" в tsconfig, чтобы устаревшие параметры работали в процессе миграции

Для монорепозиториев CLI-инструмент ts5to6 автоматизирует удаление baseUrl и вывод rootDir в нескольких пакетах. Команды с инкрементальными сборками через -watch могут ожидать примерно 25% ускорения перезапусков после миграции, что сокращает циклы обратной связи в активной разработке. Enterprise-репозитории в среднем экономят около 3 минут на 15-минутной CI-сборке только за счёт улучшений конфигурации TypeScript 6.0 - ещё до перехода на нативный Go-компилятор.

Часто задаваемые вопросы

Что такое TypeScript 6.0 и чем он отличается от TypeScript 7.0?

TypeScript 6.0 beta - последняя версия компилятора, написанного на JavaScript и TypeScript. TypeScript 7.0 использует нативный компилятор, написанный на Go (Project Corsa), стабильный с 15 января 2026 года. Сам язык TypeScript - синтаксис, система типов, совместимость с JavaScript - не изменился в обеих версиях. Отличается только цепочка инструментов компилятора.

Почему Microsoft выбрала Go, а не Rust для компилятора TypeScript?

Компилятор TypeScript опирается на разделяемую мутабельность и сборку мусора - прямой перенос на Rust потребовал бы полного переосмысления архитектуры памяти, что является не переносом, а полной переработкой. Go позволил напрямую отобразить существующие структуры данных, сохранив 100 человеко-лет инвестиций в компилятор. Сборка мусора Go совместима с существующим дизайном компилятора, а горутины обеспечивают необходимый параллелизм для ускорения в 10 раз без архитектурного переосмысления.

Сколько займёт миграция с TypeScript 5.x на 6.0?

Время миграции зависит от возраста и конфигурации репозитория. Хорошо поддерживаемый проект с явными настройками tsconfig может потребовать всего нескольких часов. Legacy-репозиторий, полагавшийся на автоматическое подключение @types, использовавший target: es5 или зависящий от outFile, может потребовать дня и более работы. CLI-инструмент ts5to6 автоматизирует наиболее рутинные изменения для монорепозиториев.

Go или Java/PHP для нового B2B-проекта - что выбрать?

Для нового B2B-сервиса с высокими требованиями к конкурентности, обработкой fintech-транзакций или интеграциями в режиме реального времени - Go даёт измеримый ROI: меньшие инфраструктурные затраты, предсказуемую латентность и прямолинейное масштабирование. Для проекта, где команда глубоко знает Java, а нагрузка не требует высокой конкурентности, стоимость переключения может не окупиться. Честный ответ требует понимания конкретных требований до рекомендации стека.

Что такое горутины и почему они важны для высоконагруженных систем?

Горутины - это легковесный примитив конкурентности в Go. Каждая горутина использует всего несколько килобайт памяти, по сравнению с мегабайтами для OS-потоков или Java-потоков. Это означает, что Go-сервис может поддерживать миллионы одновременных соединений без расхода памяти, который вынуждает к горизонтальному масштабированию системы на Java или PHP. Нативный компилятор TypeScript использует горутины для параллельного парсинга, привязки и проверки типов - именно этот механизм обеспечивает ускорение в 10 раз.

Можно ли использовать Go для fintech-приложений с высокими требованиями безопасности?

Да. Monzo, один из крупнейших облачных банков Европы, обрабатывает основные финансовые транзакции на Go - 4 000 транзакций в секунду на пике. PayPal, American Express и Nubank используют Go для производственных финансовых систем. Статическая типизация Go, явная обработка ошибок и прямолинейная модель конкурентности делают его хорошо подходящим для финансовых приложений, где важны корректность и предсказуемость. Практики безопасности - шифрование, контроль доступа, журналирование аудита, соответствие GDPR и релевантным финансовым регуляциям - являются вопросами реализации, не зависящими от выбора языка.

Когда TypeScript 7.0 на Go будет готов к продакшену для моего проекта?

TypeScript 7.0 достиг стабильного релиза 15 января 2026 года после года превью. Паритет проверки типов с компилятором на JavaScript составляет 99,6% (74 расхождения на 20 000 тест-кейсов). Для большинства проектов TypeScript 7.0 уже готов к продакшену. Командам со сложными конфигурациями типов следует сначала запустить диагностику -stableTypeOrdering на TypeScript 6.0, чтобы выявить возможные расхождения до перехода на нативный компилятор.

Заключение

TypeScript 6.0 - рубеж в истории инструментария разработчика. Он закрывает главу о компиляторе на JavaScript и открывает ту, где Go управляет самой критической инфраструктурой TypeScript. Выбор Microsoft - сделанный из прагматичных инженерных соображений, а не следования трендам - это тот же выбор, который сделали Monzo, PayPal, Uber, Salesforce и тысячи других компаний, когда им понадобились системы с предсказуемым масштабированием под нагрузкой.

• TypeScript 6.0 beta меняет пять критических параметров по умолчанию - командам с legacy-репозиториями нужно действовать до обновления
• TypeScript 7.0 на Go стабилен и даёт ускорение сборки в 10 раз на реальных кодовых базах, при этом потребление памяти примерно вдвое меньше
• Microsoft выбрала Go вместо Rust по тем же причинам, что и enterprise-команды: совместимость GC, структурное сходство с существующим кодом и параллелизм на горутинах, который прост в понимании
• Go используется в продакшене более чем в 18 000 компаниях; 2,2 миллиона профессиональных разработчиков используют его как основной язык
• Правильная точка входа для нового Go-сервиса - greenfield-проект или изолированный сервис, а не полная миграция существующих систем

Если вы создаёте fintech-сервис, высоконагруженный API или AI-интеграцию и хотите обсудить, подходит ли Go для вашей архитектуры, свяжитесь с командой Webdelo, чтобы заказать разработку сервиса на Go.