Вышел TypScript 7.0

Эта статья — перевод оригинальной статьи «Announcing TypeScript 7.0».

Также я веду телеграм канал «Frontend по‑флотски», где рассказываю про интересные вещи из мира разработки интерфейсов.

Вступление

Сегодня мы с гордостью объявляем о выходе TypeScript 7 — нативной версии TypeScript, которая работает в 10 раз быстрее!

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

В прошлом году наша команда представила следующий шаг TypeScript в масштабировании: сделать каждую часть инструментария на порядок быстрее. Наша цель заключалась в том, чтобы создать нативную версию TypeScript на Go, способную максимально эффективно использовать современное железо. Этот перенос был выполнен максимально близко к оригиналу: мы писали новый код, но сохраняли структуру и логику исходной кодовой базы, чтобы результаты оставались согласованными и совместимыми между двумя компиляторами. Главное отличие в том, что благодаря новой кодовой базе TypeScript 7 получает скорость нативного кода, многопоточность с общей памятью и ряд новых оптимизаций, которые обычно дают ускорение от 8 до 12 раз при полной сборке.

Как и любой другой релиз, TypeScript 7 доступен через npm:

npm install -D typescript

Так вы получите новый исполняемый файл tsc в своём рабочем пространстве — его можно запускать через npx tsc. Конечно, значительная часть опыта работы с TypeScript связана и с поддержкой в редакторах. Ваш любимый редактор кода должен без проблем поддерживать TypeScript 7 благодаря новой поддержке протокола Language Server Protocol (LSP), а также улучшениям скорости и многопоточности.

Используете ли вы VS Code, Visual Studio, WebStorm или любой другой современный редактор, TypeScript 7 должен работать отлично. Просто загляните в документацию вашего редактора. Например, для VS Code уже доступно специальное расширение для TypeScript 7, которым можно пользоваться прямо сейчас, а Visual Studio будет автоматически включать TypeScript 7 в зависимости от вашего рабочего пространства.

Что означает более быстрый TypeScript?

Более быстрый TypeScript звучит отлично в теории, но что это означает на практике? Возможно, проще представить это через то, где TypeScript появляется на каждом этапе разработки.

Обычный день разработки может начинаться с того, что вы открываете редактор, открываете TypeScript-файл и запускаете какую-нибудь операцию вроде поиска всех ссылок по проектам. Затем, когда вы начинаете вносить изменения, вы, вероятно, ожидаете, что будут появляться автодополнения, а ошибки будут подсвечиваться красными волнистыми линиями прямо по ходу редактирования. Когда вы — а в последнее время, возможно, и AI-агент — готовы собрать проект, вы запускаете tsc, проверяете вывод на наличие ошибок, а затем каким-то образом запускаете сгенерированный код.

Более быстрый TypeScript означает, что каждая из этих частей становится плавнее. Ожидание, пока редактор полностью загрузит проект, будет ощущаться почти мгновенным. Задержки при поиске всех ссылок, автодополнении и диагностике должны сократиться до доли прежнего времени. А когда вы запускаете tsc, возможно, в режиме --watch, вы сможете сделать цикл обратной связи короче и итерироваться быстрее, чем когда-либо.

Это видно и на реальных проектах. Более того, вы можете сами попробовать сравнить результаты на нескольких open-source проектах. Ниже — время сборки при запуске TypeScript 6 и 7 на нескольких довольно крупных open-source кодовых базах.

TypeScript 7 также обычно показывает лучшие результаты, при этом требуя меньше совокупной памяти на протяжении сборки.

Конечно, общий опыт работы не сводится только к полной сборке. На том же компьютере открытие файла с ошибкой в кодовой базе VS Code раньше занимало около 17,5 секунды — с момента запуска редактора до появления первой ошибки. С TypeScript 7 это происходит менее чем за 1,3 секунды, то есть более чем в 13 раз быстрее.

Проверен в бою и готов к продакшену

Проект TypeScript включает десятки тысяч тестов, которые создавались больше десяти лет и запускаются при каждом коммите в нашу основную ветку. Именно они помогали нам гарантировать, что каждый релиз остаётся стабильным и надёжным.

Но TypeScript 7 — не обычный релиз. Помимо нашего тестового набора, мы задействовали множество разных ресурсов, чтобы убедиться, что TypeScript 7 действительно готов к продакшену.

За последний год мы работали со многими крупными командами внутри Microsoft и за её пределами, тестируя TypeScript 7 на реальных кодовых базах. Результаты оказались исключительно положительными: целые компании сообщали, что TypeScript 7 стабилен, быстр и прост во внедрении. Например, команда VS Code недавно рассказала о своём опыте работы с предварительными версиями TypeScript 7 и о том, как они помогли ускорить цикл разработки. Мы также сотрудничали с командами Microsoft, работающими над Loop, Office, PowerBI, Teams и Xbox, чтобы убедиться, что TypeScript готов к самым крупным кодовым базам. Кроме того, такие компании, как Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero и другие, помогали нам тестировать TypeScript 7 на своих кодовых базах и давали обратную связь, чтобы сделать его лучше.

Дополнительно мы перестроили значительную часть нашей более широкой тестовой инфраструктуры для работы с TypeScript 7. В TypeScript 6 и более ранних версиях уже существовало автоматическое и запускаемое по требованию тестирование TypeScript- и JavaScript-проектов на GitHub, которое помогало выявлять регрессии в компиляторе и языковом сервисе. Теперь это тестирование вернулось и запускается уже на TypeScript 7, находя проблемы в реальных кодовых базах. Так мы можем обнаруживать пробелы в основном наборе тестов и выпускать более качественный продукт.

Сочетание прямой обратной связи, автоматических отчётов о сбоях и интенсивного тестирования заметно повлияло на качество. По нашим данным, новый языковой сервер TypeScript 7.0 фактически сократил количество неуспешных команд языкового сервера более чем на 80%, а количество падений сервера — более чем на 60% по сравнению с TypeScript 6.0.

Мы также получили впечатляющие отзывы от команд, работающих в больших масштабах:

• Инженеры Slack рассказали нам, что TypeScript 7 сократил время работы их merge queue на 40% и уменьшил время проверки типов в CI примерно с 7,5 минуты до 1,25 минуты. Раньше локальная разработка в редакторе была почти «непригодной для использования» из-за времени загрузки языкового сервера, поэтому инженеры обычно полагались на CI для полной проверки типов. TypeScript 7 смог загрузить ту же кодовую базу за несколько секунд и снова сделал локальную проверку типов практически применимой.

• Сборки в Vanta значительно ускорились: на одном из их крупнейших проектов прирост скорости достиг 9 раз.

• Аналогично команда News Services в Microsoft рассказала нам, что переход на TypeScript 7 сэкономил им 400 часов в месяц, которые раньше уходили на ожидание сборок в CI.

• В прошлом году инженеры, работавшие над PowerBI, описывали TypeScript 7 в редакторе как «спасение» при работе с их кодовой базой. Они сделали этот опыт стандартным ещё до того, как TypeScript 7 начал поддерживать функцию переименования в VS Code.

• Разработчики, работающие с монорепозиторием Loop, тоже были в восторге. Прежний опыт работы в редакторе на их масштабе описывался как непригодный для использования, тогда как работа с TypeScript 7 оказалась «потрясающей».

• Разработчики Canva рассказали нам, что языковой сервис TypeScript 7 показывает впечатляющий прирост скорости: время до появления первой ошибки в редакторе сократилось примерно с 58 секунд до 4,8 секунды.

Параллельная работа с TypeScript 6.0

Хотя TypeScript 7.0 уже вышел, он пока не поставляется с API. Мы ожидаем, что TypeScript 7.1 выйдет с новым — и другим — API, но до тех пор для нас было приоритетом обеспечить возможность запускать TypeScript параллельно с TypeScript 6.0 для утилит, которым всё ещё нужен программный доступ к компилятору, например typescript-eslint.

В рамках перехода с 6.0 на 7.0 мы опубликовали новый пакет совместимости — @typescript/typescript6. Этот пакет предоставляет исполняемый файл под названием tsc6, так что при необходимости вы можете установить TypeScript 7.0, который поставляется со своим собственным бинарником tsc, параллельно с ним и без конфликтов имён. Новый пакет также реэкспортирует API TypeScript 6.0, поэтому вы можете использовать tsc для TypeScript 7, а другие инструменты по-прежнему смогут опираться на 6.0.

Поскольку некоторые инструменты, например typescript-eslint, ожидают импорт напрямую из typescript через peer dependencies, мы рекомендуем добиться этого с помощью npm aliases. Вы сможете выполнить следующую команду:

npm install -D typescript@npm:@typescript/typescript6

или измените package.json вот так:

{  "devDependencies": {    "typescript": "npm:@typescript/typescript6@^6.0.2",  }}

Обратите внимание: после этого у вас останется только исполняемый файл tsc6. Чтобы получить tsc из версии 7.0, можно добавить ещё один alias для TypeScript 7 — и npx tsc будет просто работать с 7.0:

{  "devDependencies": {    "@typescript/native": "npm:typescript@^7.0.2",    "typescript": "npm:@typescript/typescript6@^6.0.2"  }}

Ночные сборки и @typescript/native-preview

До сих пор большинство разработчиков устанавливали TypeScript 7 через пакет @typescript/native-preview. Этот пакет поставлял ночные сборки новой кодовой базы и отлично послужил сообществу — у него было более 8,5 миллиона загрузок в неделю!

Однако в дальнейшем ночные сборки скоро снова будут публиковаться в стандартном пакете typescript с тегом next. Установить его можно так:

npm install -D typescript@next

Гибкое масштабирование: параллелизация и настройки

TypeScript 7.0 теперь выполняет многие этапы параллельно, включая парсинг, проверку типов и генерацию выходных файлов. Некоторые из этих этапов, например парсинг и генерация, в основном могут выполняться независимо для разных файлов. Поэтому параллелизация автоматически хорошо масштабируется на крупных кодовых базах и создаёт сравнительно небольшие накладные расходы. Но не каждый этап сборки TypeScript легко распараллелить.

TypeScript 7 вводит экспериментальные флаги --checkers и --builders, которые позволяют тонко настраивать поведение параллелизации для более сложных этапов, таких как проверка типов и сборка project references. Также появляется флаг --singleThreaded, который полностью отключает параллелизацию. Это может быть полезно для отладки или запуска в средах с ограниченными ресурсами.

Параллелизация проверки типов

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

Чтобы включить параллелизацию и при этом избежать этих проблем, TypeScript 7.0 создаёт фиксированное число воркеров проверки типов, у каждого из которых есть собственное представление о мире. Эти воркеры могут в итоге дублировать часть общей работы, но при одних и тех же входных файлах они всегда будут делить их одинаково и выдавать одинаковые результаты.

По умолчанию используется 4 воркера проверки типов, но это можно настроить с помощью нового флага --checkers. Возможно, на крупных кодовых базах увеличение этого числа дополнительно ускорит сборки, особенно на типичных машинах с большим количеством CPU-ядер, но обычно ценой будет повышенное потребление памяти. Например, в таблице выше мы запускали TypeScript 7 со значением по умолчанию — --checkers 4. Вот как выглядят результаты на той же машине с --checkers 8.

Как видно, эти кодовые базы получают дополнительный прирост скорости за счёт выделения большего числа ядер, но результаты будут отличаться в зависимости от проекта и конкретной машины.

С другой стороны, на машинах с меньшим количеством CPU-ядер и меньшим объёмом памяти, например на CI-раннерах, вам может быть полезно уменьшить это число, чтобы избежать лишних или случайных накладных расходов. Можно указать значение вплоть до --checkers 1, что фактически сделает проверку типов однопоточной и устранит дублирование работы.

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

Параллелизация сборщика project references

TypeScript 7.0 может распараллеливать сборку внутри одного проекта, но теперь он также умеет собирать несколько проектов одновременно. Это поведение настраивается с помощью нового флага --builders, который управляет количеством параллельных сборщиков project references, способных работать одновременно при запуске в режиме --build. Это может быть особенно полезно для монорепозиториев с большим количеством проектов.

Как и в случае с --checkers, увеличение числа сборщиков может ускорить сборки, но за это, возможно, придётся заплатить повышенным потреблением памяти. Кроме того, этот параметр даёт мультипликативный эффект вместе с --checkers, поэтому важно найти правильный баланс для вашей машины и кодовой базы. Например, сборка с --checkers 4 --builders 4 допускает одновременный запуск до 16 проверщиков типов, что может оказаться избыточным.

В отличие от --checkers, изменение количества сборщиков не должно приводить к разным результатам. Однако сборка project references по своей природе ограничена графом зависимостей между проектами — за исключением проверки типов на кодовых базах, которые используют --isolatedDeclarations и отдельную синтаксическую генерацию файлов деклараций.

Однопоточный режим

В некоторых случаях может быть полезно принудительно включить однопоточную работу всего компилятора. Это может пригодиться для отладки, сравнения производительности TypeScript 6 и 7, внешней оркестрации параллельных сборок или запуска в средах с очень ограниченными ресурсами. Чтобы включить однопоточный режим, можно использовать новый флаг --singleThreaded. Он не только ограничит количество воркеров проверки типов до одного, но и гарантирует, что парсинг и генерация выходных файлов тоже будут выполняться в одном потоке.

Улучшенный режим —watch

TypeScript 7 поставляется с полностью переработанным режимом --watch. Теперь --watch работает на новой основе, созданной на базе file-watcher из бандлера Parcel, и обеспечивает эффективное и стабильное отслеживание изменений файлов на разных платформах.

Когда наша команда начала переносить логику отслеживания файлов, мы столкнулись с несколькими сложностями, связанными с кросс-платформенным наблюдением за файлами в Go. В стандартной библиотеке нет встроенного API для отслеживания файлов, а у существующих сторонних библиотек, которые мы изучали, были разные проблемы со стабильностью, производительностью, кросс-платформенной поддержкой или интеграцией с инструментами сборки. Мы смогли построить решения на основе периодического polling — регулярной проверки изменений файлов, — и в целом это работало в разных операционных системах. Однако такой подход был вычислительно дорогим, особенно на крупных проектах с большим количеством зависимостей в node_modules. Даже с динамическими стратегиями планирования мы обнаружили, что решения, основанные только на polling, слишком затратны для общего использования.

На протяжении многих лет Visual Studio Code полагается на @parcel/watcher, а в последние годы TypeScript в VS Code косвенно использует его возможности отслеживания файлов. Это выглядело многообещающе, но одна из проблем Parcel watcher для нас заключалась в том, что он написан на C++, а значит, для сборки требует полноценный C++ toolchain. Учитывая наш положительный опыт использования Parcel watcher в VS Code, мы изучили возможность перенести его на Go с несколькими минимальными ассемблерными прослойками, чтобы не добавлять новую зависимость от toolchain.

Эксперимент оказался успешным: то, что начиналось как очень прямой перевод с C++ на Go, затем было доработано до идиоматичного Go-кода, который при этом по-прежнему проходит перенесённый набор тестов. Watcher представляет собой самодостаточный пакет, который позволил нам сохранить чёткое разделение ответственности между тем, за чем мы хотим наблюдать, и тем, зачем мы это делаем. Теперь мы видим заметное улучшение потребления ресурсов в режиме --watch на разных платформах и уже получаем положительные отзывы от первых пользователей TypeScript 7.

Мы хотим отдельно поблагодарить Девона Говетта: его работа над Parcel принесла огромную пользу как проекту Visual Studio Code, так и TypeScript. Мы надеемся, что со временем этот порт даст новые возможности и идеи для оригинальной кодовой базы Parcel watcher.

Обновления после версии 5.x и новое поведение в 6.0

TypeScript 7.0 создан так, чтобы быть совместимым с поведением проверки типов и командной строки в TypeScript 6.0. Практически любой TypeScript-код, который без ошибок компилируется в TypeScript 6.0 — с включённым флагом stableTypeOrdering и без установленного флага ignoreDeprecations, — должен компилироваться в TypeScript 7.0 точно так же.

При этом TypeScript 7.0 перенимает новые значения по умолчанию из 6.0 и выдаёт жёсткие ошибки при использовании любых флагов и конструкций, объявленных устаревшими в TypeScript 6.0. Это важно, поскольку 6.0 всё ещё относительно новая версия, и многим проектам придётся адаптироваться к её новому поведению. Мы рекомендуем разработчикам сначала перейти на TypeScript 6.0, чтобы упростить дальнейший переход на TypeScript 7.0. Подробнее об этих deprecation-изменениях можно также прочитать в статье о релизе TypeScript 6.0.

Вкратце, основные изменения значений конфигурации по умолчанию такие:

• strict теперь по умолчанию равен true.

• module по умолчанию имеет значение esnext.

• target по умолчанию указывает на текущую стабильную версию ECMAScript, которая непосредственно предшествует esnext.

• noUncheckedSideEffectImports по умолчанию равен true.

• libReplacement по умолчанию равен false.

• stableTypeOrdering по умолчанию равен true, и его нельзя отключить.

• rootDir теперь по умолчанию равен ./, а вложенные директории с исходным кодом нужно указывать явно.

• types теперь по умолчанию равен [], а старое поведение можно вернуть, задав значение ["*"].

Мы считаем, что изменения в rootDir и types могут оказаться самыми «неожиданными», но их легко смягчить. Проектам, где tsconfig.json находится за пределами директории вроде src, достаточно явно указать rootDir, чтобы сохранить прежнюю структуру директорий.

  {      "compilerOptions": {          // ...+         "rootDir": "./src"      },      "include": ["./src"]  }

Что касается изменения types, проектам, которые зависят от конкретных глобальных деклараций, нужно будет перечислить их явно. Например:

  {      "compilerOptions": {          // Explicitly list the @types packages you need (e.g. bun, mocha, jasmine, etc.)+         "types": ["node", "jest"]      }  }

Устаревшие возможности, которые теперь превращены в жёсткие ошибки и больше не имеют эффекта:

• target: es5 больше не поддерживается.

• downlevelIteration больше не поддерживается.

• moduleResolution: node / node10 больше не поддерживаются; вместо них рекомендуется использовать nodenext или bundler.

• module: amd, umd, systemjs, none больше не поддерживаются; вместо них рекомендуется использовать esnext или preserve вместе с бандлерами либо браузерным разрешением модулей.

• baseUrl больше не поддерживается, а paths можно обновить так, чтобы пути были относительными к корню проекта, а не к baseUrl.

• moduleResolution: classic больше не поддерживается; рекомендуемые заменыbundler или nodenext.

• esModuleInterop и allowSyntheticDefaultImports нельзя устанавливать в false.

• alwaysStrict считается равным true, и его больше нельзя установить в false.

• Ключевое слово module нельзя использовать в объявлениях namespace.

• Ключевое слово asserts нельзя использовать в импортах; вместо него нужно использовать with, чтобы соответствовать развитию синтаксиса import attributes в ECMAScript.

• Директивы /// <reference no-default-lib /> больше не учитываются при skipDefaultLibCheck.

• Сборки из командной строки не могут принимать пути к файлам, если в текущей директории есть файл tsconfig.json, если только явно не передан флаг --ignoreConfig.

Шаблонные литеральные типы теперь сохраняют кодовые точки Unicode

TypeScript 7.0 теперь более естественно обрабатывает кодовые точки Unicode при выводе типов из шаблонных литеральных типов. Например:

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;type Result = HeadTail<"abc">;//   ^// In 7.0: ["", "abc"]// Previously: ["\ud83d", "\ude00abc"]

Раньше TypeScript в этом случае следовал поведению JavaScript с индексацией UTF-16 и разбивал "😀" на две половины суррогатной пары (\ud83d и \ude00). Технически это соответствовало индексации в JavaScript — например, выведенный тип Head был равен "😀abc"[0], — но обычно это было не то, чего ожидали разработчики. Кроме того, это могло приводить к появлению строковых литеральных типов с непарными суррогатами, которые не имеют осмысленного семантического значения.

Это breaking change для манипуляций со строками на уровне типов, которые намеренно моделировали кодовые единицы UTF-16, например для некоторых утилит вычисления длины строки. На практике мы ожидаем, что новое поведение окажется полезнее и менее неожиданным: теперь вывод типов из шаблонных литералов следует той же интуиции, что и перебор строки через for...of или её разворачивание через [...str], где "😀" считается одной единицей.

Отличия JavaScript

Пока мы переносили существующую кодовую базу, мы также воспользовались возможностью пересмотреть то, как работает наша поддержка JavaScript.

Изначально TypeScript поддерживал JavaScript-файлы за счёт JSDoc-комментариев и распознавания определённых паттернов кода для анализа и вывода типов. Часто это опиралось на популярные практики написания кода, но иногда — на то, что могли писать пользователи и что понимали Closure и инструмент генерации документации JSDoc. Такой подход помогал разработчикам со слабо типизированными JSDoc-кодовыми базами, но для хорошей работы требовал множества компромиссов и особых случаев. Кроме того, во многих аспектах он расходился с тем, как TypeScript анализирует файлы .ts.

В TypeScript 7.0 мы переработали поддержку JavaScript, чтобы она была более согласована с тем, как мы анализируем TypeScript-файлы. Некоторые отличия включают следующее:

• Значения нельзя использовать там, где ожидаются типы — вместо этого нужно писать typeof someValue.

• @enum больше не распознаётся особым образом — создайте @typedef на основе (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration].

• Отдельный ? больше нельзя использовать как тип — вместо него используйте any.

• @class не делает функцию конструктором — вместо этого используйте объявление класса.

• Постфиксный ! не поддерживается — просто используйте T.

• Имена типов должны определяться внутри тега @typedef, то есть /** @typedef {T} TypeAliasName /, а не рядом с идентификатором, например /* @typedef {T} */ TypeAliasName;.

• Синтаксис функций в стиле Closure, например function(string): void, больше не поддерживается — вместо него используйте сокращённый синтаксис TypeScript, например (s: string) => void.

Кроме того, некоторые JavaScript-паттерны, такие как создание алиаса для this и полная перезапись prototype функции, больше не обрабатываются особым образом.

Пока часть нашей поддержки JS находится в процессе изменений, мы обновляем файл CHANGES.md, чтобы подробнее фиксировать различия между TypeScript 6.0 и 7.0.

Опыт работы в редакторе

Как мы уже упоминали выше, улучшения производительности TypeScript 7.0 не ограничиваются работой из командной строки — они также распространяются на опыт работы в редакторе. Для пользователей VS Code у нас есть отдельное расширение для TypeScript 7. После установки оно автоматически станет вариантом по умолчанию. В любой момент его можно отключить и снова включить через команды “Disable TypeScript 7 Language Server” и “Enable TypeScript 7 Language Server” в палитре команд. В ближайшие недели поддержка TypeScript 7 будет поставляться уже в составе самого VS Code.

Для пользователей Visual Studio последняя версия IDE будет автоматически включать TypeScript 7 в зависимости от рабочего пространства. Вам не нужно будет ничего делать иначе.

Разумеется, TypeScript 7 должен отлично работать в любом редакторе на ваш выбор. Новая основа построена на Language Server Protocol (LSP) и способна использовать несколько потоков, чтобы обслуживать одновременные запросы как можно быстрее.

С момента первого появления мы добавили недостающую функциональность: автоимпорты, раскрываемые hover-подсказки, inlay hints, code lenses, переход к исходному определению, связанное редактирование JSX и автодополнение тегов, а также многое другое. Возможности, которых не хватало в бете TypeScript 7.0, такие как семантическая подсветка, “sort imports”, “remove unused imports” и другие, теперь уже добавлены.

Кроме того, за последние несколько месяцев мы продолжили улучшать производительность и стабильность. Мы перестроили значительную часть инфраструктуры тестирования и диагностики, чтобы держать высокую планку качества. В частности, теперь мы можем проводить fuzz-тестирование языкового сервера на крупнейших TypeScript- и JavaScript-кодовых базах на GitHub. Как мы уже говорили выше, новый языковой сервер TypeScript 7 значительно стабильнее, чем в TypeScript 6.

TypeScript и встроенные языки

Стоит отдельно отметить, что рабочие процессы, использующие Vue, MDX, Astro, Svelte и другие подобные инструменты, скорее всего, пока не смогут воспользоваться TypeScript 7. Аналогично специализированная проверка типов внутри шаблонов, например в Angular, также, вероятно, пока не будет использовать TypeScript 7. Главная причина в том, что TypeScript 7 ещё не предоставляет стабильный программный API, поэтому инструменты, такие как Volar, которые встраивают TypeScript в собственные компиляторы и языковые сервисы, сейчас могут полагаться только на TypeScript 6.0. Мы ожидаем, что это временная проблема, и намерены предоставить для неё решение. Мы будем активно работать с мейнтейнерами этих проектов, чтобы TypeScript 7 поддерживал такие сценарии.

До тех пор мы рекомендуем командам использовать TypeScript 7 в сценариях, где не требуются плагины языкового сервера. Проекты на Angular могут комбинировать TypeScript 7 для быстрой проверки ошибок по всему проекту через CLI с помощью tsc и TypeScript 6.0 для поддержки в редакторе. Проектам, использующим Vue, MDX, Astro, Svelte и другие подобные инструменты, пока нужно продолжать использовать TypeScript 6.0. В VS Code пользователи могут просто выполнить команду “Disable TypeScript 7 Language Server”, чтобы вернуться к TypeScript 6.0.

Дальнейший путь

TypeScript 7.0 — важная веха для проекта TypeScript. Этот перенос был главным фокусом нашей команды больше года, и теперь, когда 7.0 вышел, мы вернёмся к работе над новыми возможностями, улучшением эргономики, дальнейшим приростом производительности и реализацией нового API для более широкой экосистемы. Хотя это звучит масштабно, мы ожидаем примерно такой же график релизов, как и до TypeScript 7.0: новые версии с полноценными возможностями будут выходить каждые 3–4 месяца. Поскольку TypeScript 7.1 уже на горизонте, мы надеемся закрыть оставшиеся пробелы и помочь сообществу двигаться вперёд.

Мы также призываем вас делиться своим опытом использования TypeScript 7.0 онлайн. Вы можете подписаться на нас и отмечать @typescriptlang.org в Bluesky, @typescript@fosstodon.org в Mastodon или @typescript в Twitter — расскажите нам и другим, что вы думаете о TypeScript 7.

Мы знаем, что этот новый релиз будет невероятно ценным для экосистемы TypeScript. Надеемся, он сделает ваш повседневный опыт написания кода быстрее, приятнее, продуктивнее и радостнее.

Добро пожаловать в нативную эпоху инструментария TypeScript.

Удачного хакинга!

— Команда TypeScript