Недавно команда 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 и:
Запустили одинаковые последовательности действий для двух серверов. (Полная автоматизация через макросы затруднена: они не пишут действия мышью и могут воспроизводиться нестабильно.)
Записали логи времени выполнения запросов.
Сравнили медианы — чтобы исключить редкие лаги.
Статистика проекта Typescript
TypeScript быстрый, запросы обрабатываются в микросекундах–десятках миллисекунд. Но медиана — более честная метрика.
Наблюдения
textDocument/definition, textDocument/references, textDocument/implementation
textDocument/typeDefinition
Время выполнения textDocument/typeDefinition
textDocument/completion
Время выполнения textDocument/completion
completionItem/resolve
Время выполнения completionItem/resolve
textDocument/documentHighligt, textDocument/documentSymbol
textDocument/hover
Время выполнения textDocument/hover
Сводный график времени выполнения lsp запросов
Пока можно осторожно сказать:
- 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 быстрее, стабильнее и удобнее.