Недавно команда TypeScript представила TypeScript 7 — новую версию, переписанную на Go. Главные обещания: до 10× ускорения компиляции и до 8× более быстрый старт анализа проекта. Но самое интересное спрятано чуть глубже: вместе с TS-Go появляется полноценный LSP-сервер, встроенный прямо в компилятор.

Для многих IDE это шаг вперёд.
Для нас, команды OpenIDE, — это ещё и освобождение от ограничений, с которыми TypeScript приходилось поддерживать долгие годы.

В статье делимся контекстом, собственными экспериментами и наблюдениями — что уже работает, что нет и как новый сервер ощущается в реальной IDE.

Почему это важно для OpenIDE

Мы активно развиваем поддержку TypeScript/JavaScript. И здесь важно помнить исторический факт: официальный tsserver не являлся LSP-сервером. Он появился раньше стандарта LSP и использовал собственный RPC-протокол — идеально для VS Code, но неудобно для всех остальных.

Чтобы интегрировать TS/JS в OpenIDE, приходилось держать «мост» между IDE и нестандартным сервером, вручную сопоставлять команды, обрабатывать исключения и частные случаи. Это была нормальная инженерная реальность… но не самая приятная.

С появлением TypeScript-Go ситуация меняется:

Впервые в комплекте с компилятором идёт официальный LSP-сервер

Это означает:

• единый формат взаимодействия с IDE,

• предсказуемую структуру запросов и ответов,

• меньше обходных путей и кастомных адаптаций,

• меньше расхождений с VS Code,

• и проще развитие поддержки ЯП внутри IDE.

По сути, язык впервые предоставляет «всё в одном»: компилятор + анализатор + языковой сервер, собранные вокруг одного источника истины.

Но что именно даёт компилятор IDE?

Компилятор — это не просто превращение TS в JS. Чтобы компилировать, нужно:

• разбирать синтаксис,

• определять типы,

• резолвить символы и импорты,

• отслеживать зависимости между файлами,

• делать инкрементальный анализ.

То есть компилятор обладает наиболее полным и точным знанием о коде.
Именно поэтому большинство современных языков (Go, Rust, Kotlin, Swift, Zig) идут в сторону официального LSP поверх компилятора.

Что уже работает, а что нет

Пока в TypeScript-Go заметны недочёты:

• не реализованы semanticTokens, foldingRange и часть других методов;

• статус Language service и API пока не позволяют добавить поддержку Angular и Vue;

• есть проб��емы с резолвингом модулей — и да, они воспроизводятся и в VS Code, это важно.

То есть если что-то «ломается» — это не проблема конкретной IDE, а состояние экосистемы на ранней стадии.

Как мы тестировали производительность

Цифры Microsoft касаются компилятора. Но поведение IDE определяется временем ответа LSP-сервера на сотни операций:

• hover,

• completion,

• definition,

• references,

• codeAction,

• операции фонового анализа.

Поэтому мы решили проверить именно реакцию LSP-сервера.

Методика

Мы взяли проект самого TypeScript, открыли его в OpenIDE и:

1. Запустили одинаковые последовательности действий для двух серверов.
   (Полная автоматизация через макросы затруднена: они не пишут действия мышью и могут воспроизводиться нестабильно.)

2. Записали логи времени выполнения запросов.

3. Сравнили медианы — чтобы исключить редкие лаги.

TypeScript быстрый, запросы обрабатываются в микросекундах–десятках миллисекунд. Но медиана — более честная метрика.

Наблюдения

Пока можно осторожно сказать:

• TypeScript-Go действительно быстрее в ряде навигационных запросов.

• Hover/definition/codeAction работают примерно так же, как и в старом сервере.

• Иногда можно увидеть десятикратную разницу в выполнении операции, но ее стоит рассматривать аккуратно — такое может быть следствием кэширования или особенностей выполнения.

То есть новых «магических ускорений» в IDE пока нет — но переход на LSP даёт более структурную выгоду: архитектура становится проще, чище и надёжнее.

Попробуйте сами — поддержка TS-Go уже встроена в OpenIDE

Мы добавили возможность переключиться на TypeScript-Go в плагине WebTools. Можно протестировать всё прямо в рабочем проекте:

Settings → Languages & Frameworks → Web Tools → TypeScript version → “TypeScript-Go (Experimental)”

Сравните поведение, дайте фидбек — нам важно видеть реальные сценарии.

Что дальше

Мы ожидаем, что в ближайшие месяцы:

• появятся отсутствующие методы LSP,

• улучшится резолвинг,

• стабилизируется работа плагинов,

• экосистема выйдет из стадии эксперимента.

Для IDE это долгожданное выравнивание: наконец появится официальный, стандартный, предсказуемый способ интеграции TS/JS.

В OpenIDE мы продолжаем развивать поддержку веб-технологий так, чтобы новые инструменты органично становились частью ежедневной разработки. Следите за обновлениями здесь и в нашем Telegram канале: впереди ещё много улучшений, которые сделают работу с JavaScript и TypeScript в OpenIDE быстрее, стабильнее и удобнее.