Typescript что это и зачем
Введение в TypeScript
Что такое TypeScript
TypeScript представляет язык программирования на основе JavaScript.
Однако, казалось бы, зачем нужен еще один язык программирования для клиентской стороны в среде Web, если со всей той же самой работой прекрасно справляется и традиционный JavaScript, который используется практически на каждом сайте, которым владеет множество разработчиков и поддержка которого в сообществе программистов довольно высока. Но TypeScript это не просто новый JavaScript.
Во-вторых, TypeScript реализует многие концепции, которые свойствены объектно-ориентированным языкам, как, например, наследование, полиморфизм, инкапсуляция и модификаторы доступа и так далее.
В-третьих, потенциал TypeScript позволяет быстрее и проще писать большие сложные комплексные программы, соответственно их легче поддерживать, развивать, масштабировать и тестировать, чем на стандартном JavaScript.
Генерируемый компилятором TypeScript код JS поддерживается подавляющим большинством браузеров. Хотя в процессе разработки мы можем сами задать целевой стандарт ECMAScript.
Как использовать TypeScript? Поскольку данный язык является OpenSource, то все его инструменты доступны для всех желающих. Для работы с TypeScript мы можем использовать как Windows, так и Linux и MacOS.
Сам компилятор TS можно установить с помощью команды менеджера пакетов npm, который используется в Node.js:
Для написания кода на языке TypeScript можно использовать любой самый простейший текстовый редактор. Многие текстовые редакторы и среды разработки, например, Visual Code Studio, Atom, Sublime, Visual Studio, Netbeans, WebStorm и другие, имеют поддержку TypeScript на уровне плагинов, что позволяет воспользоваться рядом преимуществом, например, подцветкой кода или всплывающей подсказкой по типам и конструкциям языка.
TypeScript для бэкенд-разработки
TypeScript пока не успел хорошо зарекомендовать себя среди бэкенд-разработчиков. Вероятно, потому что известен как набор декларативных файлов, позволяющих добавить в JavaScript некоторую типизацию. Но, все же, есть масса логики, на представление которой ушли бы десятки строк на Java, и которую можно представить всего в нескольких строках TypeScript.
Масса фич, о которых говорят как о характерных чертах TypeScript, на самом деле относятся к JavaScript. Но TypeScript также можно рассматривать как самостоятельный язык, обладающий определенным синтаксическим и концептуальным сходством с JavaScript. Поэтому давайте ненадолго отвлечемся от JavaScript и рассмотрим TypeScript сам по себе: это красивый язык с исключительно мощной, но при этом гибкой системой типов, с кучей синтаксического сахара и, наконец, с нуль-безопасностью!
Мы разместили на Github репозиторий со специально разработанным веб-приложением на Node/TypeScript, а также с некоторыми дополнительными объяснениями. Там есть также ветка продвинутой сложности с примером луковой архитектуры и более нетривиальными концепциями из области типизации.
Знакомство с TypeScript
Начнем с азов: TypeScript – это асинхронный язык для функционального программирования, который, тем не менее, поддерживает классы и интерфейсы, а также публичные, приватные и защищенные атрибуты. Поэтому программист при работе с этим языком приобретает значительную гибкость в работе на уровне микроархитектуры и стиля кода. Компилятор TypeScript можно конфигурировать динамически, то есть, контролировать, какие типы импортов разрешены, если функциям требуются явные возвращаемые типы, а также активировать ли проверки на нуль во время компиляции.
Поскольку TypeScript компилируется в обычный JavaScript, в качестве среды исполнения для бэкенда используется Node.js. В отсутствие всеобъемлющего фреймворка, который напоминал бы Spring, имеем, что типичный веб-сервис будет использовать более гибкий фреймворк, служащий веб-сервером (отличный пример такого рода — Express.js). Следовательно, он получится менее «магическим», а его базовая настройка и конфигурирование будут устроены более явно. В таком случае сравнительно сложные сервисы также потребуют сильнее повозиться с настройкой. С другой стороны, настройка сравнительно мелких приложений не составляет труда, причем, осуществима практически без предварительного изучения фреймворка.
Управление зависимостями без труда осуществляется при помощи гибкого, но при этом мощного менеджера пакетов Node, npm.
Основы
Обратите внимание: поскольку в TypeScript используется вывод типов, объект User можно инстанцировать, даже если не предусмотрен класс User как таковой. Такой структуро-подобный подход часто выбирается при работе с чистыми сущностями данных и не требует никаких методов или внутреннего состояния.
Дженерики в TypeScript выражаются примерно таким же образом, что и в Java:
Мощная система типов
В основе мощной системы типов TypeScript лежит механизм вывода типов; также здесь поддерживается статическая типизация. Однако аннотации к статическим типам не являются обязательными, если возвращаемый тип или тип параметра можно вывести, исходя из контекста.
TypeScript также позволяет использовать типы объединений, частичные типы и пересечения типов, благодаря чему язык приобретает значительную гибкость, в то же время избегая ненужной сложности. В TypeScript также можно использовать в качестве типа конкретное значение, что невероятно удобно во множестве ситуаций.
Перечисления, вывод типов и типы объединений
Рассмотрим обычную ситуацию, в которой у статуса заказа должно быть типобезопасное представление (в виде перечисления), но также требуется и строковое представление для сериализации в формате JSON. В Java для этого объявлялось бы enum вместе с конструктором и геттером для строковых значений.
В первом примере перечисления TypeScript позволяют напрямую добавить строковое представление. Таким образом, у нас в распоряжении оказывается типобезопасное представление в виде перечисления, автоматически сериализующее связанное с ним строковое представление.
Правда, оказывается, что при совместном использовании друг с другом вывода типов и типов-объединений эта задача может быть решена еще проще:
Компилятор TypeScript примет в качестве действительного значения статуса заказа лишь такую строку, которая была ему предоставлена (обратите внимание: при этом все равно будет необходима валидация входящих данных JSON).
В принципе, такие представления типов работают с чем угодно. Тип вполне может представлять собой объединение, состоящее из строкового литерала, числа и любого другого пользовательского типа или интерфейса. Более интересные примеры можете посмотреть в руководстве по продвинутой типизации TypeScript.
Лямбды и функциональные аргументы
Поскольку TypeScript – это язык для функционального программирования, в его ядре есть поддержка анонимных функций, также именуемых лямбдами.
Асинхронное программирование
Обратите внимание: хотя, вышеприведенный код и выглядит синхронным, это лишь видимость (поскольку здесь возвращается еще один промис).
Оператор расширения и rest-оператор: упрощаем себе жизнь
При использовании Java обработка данных, конструирование, слияние и деструктурирование объектов часто в огромном количестве плодят стереотипный код. Классы приходится определять, конструкторы, геттеры и сеттеры – генерировать, а объекты – инстанцировать. В тестовых кейсах зачастую требуется активно прибегать к рефлексии на мок-экземпляры закрытых классов.
В TypeScript со всем этим можно справляться играючи, пользуясь его сладким типобезопасным синтаксическим сахаром: операторами расширения и rest-операторами.
Для начала воспользуемся оператором расширения массива… чтобы распаковать массив:
Разумеется, это удобно, но настоящий TypeScript начинается, стоит вам осознать, что то же самое можно делать и с объектами:
Рассмотрим, что здесь происходит. В принципе, объект updated создается при помощи конструктора с фигурными скобками. Внутри этого конструктора каждый параметр фактически создает новый объект, начиная работу слева.
Использование оператора расширения для создания копий иммутабельного объекта – очень безопасный и и быстрый способ обработки данных. Отметим: оператор расширения создает неглубокую копию объекта. Элементы с глубиной более единицы в таком случае копируются как ссылки.
У оператора расширения также есть эквивалент-деструктор, именуемый object rest:
Здесь самое время просто откинуться на спинку кресла и вообразить весь тот код, который пришлось бы написать на Java для выполнения таких операций, как показанные выше.
Заключение. Немного о достоинствах и недостатках
Производительность
Поскольку TypeScript по своей природе является асинхронным и обладает быстрой средой исполнения, существует много сценариев, в которых сервис на Node/TypeScript может потягаться с сервисом на Java. Такой стек особенно хорош для операций ввода/вывода и будет отлично работать с эпизодическими краткими блокирующими операциями, например, при пересчете размеров новой картинки в профиле. Однако, если основная задача сервиса заключается в выполнении серьезных вычислений на CPU, Node и TypeScript наверняка не слишком хорошо подойдут для этого.
Тип number
Экосистема
Учитывая популярность Node.js, неудивительно, что сегодня для него существуют сотни тысяч пакетов. Но, поскольку Node моложе Java, многие пакеты пережили не так много версий, а качество кода в некоторых библиотеках явно оставляет желать лучшего.
Среди прочих стоит упомянуть несколько качественных библиотек, с которыми очень удобно работать: например, для веб-серверов, внедрения зависимостей и аннотаций контроллеров. Но, если сервис будет серьезно зависеть от многочисленных и хорошо поддерживаемых сторонних программ, то лучше воспользоваться Python, Java или Clojure.
Ускоренная разработка фич
Как мы могли убедиться выше, одно из важнейших достоинств TypeScript заключается в том, как просто на этом языке выражать сложную логику, концепции и операции. Тот факт, что JSON является неотъемлемой частью этого языка, а сегодня широко используется в качестве формата сериализации данных при передаче данных и работе с документ-ориентированными базами данных, в таких ситуациях кажется естественным прибегнуть к TypeScript. Настройка сервера Node осуществляется очень быстро, как правило, без излишних зависимостей; так вы сэкономите ресурсы системы. Вот почему комбинация Node.js с сильной системой типов TypeScript так эффективна для создания новых фич в кратчайшие сроки.
Наконец, TypeScript хорошо сдобрен синтаксическим сахаром, поэтому разработка на нем идет приятно и быстро.
Чем меня разочаровал Typescript и стоит ли он того?
Прежде чем начать, хочу упомянуть, что я фанат TypeScript. Это мой основной язык программирования для фронтенд проектов на React и для любой бекенд работы, которую я выполняю в Node. Я полностью за Typescript, но есть моменты, которые меня беспокоят и про которые я и хотел рассказать этой статьей.
Я писал исключительно на TypeScript в течение последних трех лет для множества разных компаний, так что на мой взгляд, TypeScript как минимум что-то делает правильно или закрывает определённые потребности.
Несмотря на своё несовершенство, TypeScript вошёл в мейнстрим фронтенд разработки и занимает седьмое место в списке наиболее востребованных языках программирования по версии HackerRank developer skills report.
Любой команде разработчиков, неважно, большая она или маленькая, пишет на TypeScript или нет, ради безопасности всегда стоит:
TypeScript не является надежной системой типов
Я думаю, что это, возможно, главная проблема с TypeScript, но прежде позвольте мне определить, что такое надежные и ненадежные системы типов.
Надежная система типов
Надежная система типов гарантирует, что ваша программа не попадет в недопустимые состояния. Например, если статическим типом выражения является string, при его вычислении во время выполнения вы гарантированно получите только string.
В надежной системе типов вы никогда не будете находиться в ситуации, когда выражение не соответствует ожидаемому типу, будь то во время компиляции или во время выполнения.
Существуют, конечно же, различные степени надежности, а также различные интерпретации надежности. TypeScript является в некоторой степени надежным и ловит ошибки типа:
Ненадежная система типов
Иметь надежную или «доказуемо правильную» систему типов не является нашей целью. Вместо этого мы стремимся соблюсти баланс между правильностью и производительностью.
Это означает, что нет гарантии, что переменная имеет определенный тип во время выполнения. Я могу проиллюстрировать это на следующем несколько надуманном примере:
Приведенный выше код не работает, поскольку известно, что a.x — это число из интерфейса A. К сожалению, после пары финтов с переназначением оно превращается в строку и данный код компилируется, но с ошибками во время выполнения.
К сожалению, данное выражение компилируется без ошибок:
То, что надежность не является целью языка, вероятно, одна из самых крупных проблем TypeScript. Я продолжаю получать много ошибок runtime error во время выполнения, которые не ловит tsc компилятор, но которые были бы замечены компилятором, если бы в TypeScript существовала надежная система типов. TypeScript сейчас одной ногой в лагере «надежных» языков, а другой в «ненадежных». Этот подход, состоящий из полумер основан на типе any, о котором я расскажу позже.
Меня фрустрирует факт, что количество тестов, которые я пишу, нисколько не уменьшилось с переходом на TypeScript. Когда я только начинал, то ошибочно решил, что смогу сократить тягомотную рутину написания большого количества юнит тестов.
TypeScript бросает вызов существующему порядку вещей, утверждая, что снижение когнитивных затрат при использовании типов важнее, чем их надежность.
Я понимаю, почему TypesScript выбрал такой путь и есть мнение, что TypeScript не был бы так популярен, если бы надежность системы типов была бы 100% гарантирована. Это мнение не выдержало проверки — язык Dart стремительно набирает популярность, одновременно с повсеместным использованием Flutter. А утверждается, что надежность типов является целью Dart.
Ненадежность и различные способы, которыми TypeScript предоставляет «аварийный выход» из строгой типизации, делают его менее эффективным и, к сожалению, делают его просто «лучше, чем ничего» в данный момент. Я был бы рад, если по мере роста популярности TypeScript стало доступно больше опций компилятора, позволяющих опытным пользователям стремиться к 100% надежности.
TypeScript не гарантирует никакой проверки типов во время выполнения
Проверка типов во время выполнения не является целью TypeScript, поэтому моё пожелание, вероятно, никогда не сбудется. Проверка типов во время выполнения полезна, например, при работе с данными JSON, возвращаемыми из вызовов API. Можно было бы избавится от целой категории ошибок и множества юнит тестов, если бы мы могли контролировать эти процессы на уровне системы типов.
Так как мы не можем ничего гарантировать во время выполнения, легко может случиться такое:
Есть несколько вспомогательных библиотек, таких как io-ts, что замечательно, но это может означать, что вам придется дублировать свои модели.
Страшный тип any и опция strict
Тип any означает «любой», и компилятор допускает любую операцию или присваивание переменной с таким типом.
TypeScript хорошо работает для небольших вещей, но люди склонны ставить тип any на все, что занимает больше одной минуты. Недавно я работал над Angular-проектом и видел много такого кода:
TypeScript позволяет вам забыть о системе типов.
Вы можете сломать тип чего угодно при помощи any:
Опция strict включает следующие параметры компилятора, которые делают все более надежным:
Распространение any может разрушить надежность вашего кода.
Заключение
Я должен повторить, что я фанат TypeScript и использую его в своей повседневной работе, но я чувствую, что он несовершенен и шумиха вокруг него не совсем оправдана. Airbnb утверждает, что TypeScript помог предотвратить 38% ошибок. Я очень скептически отношусь к настолько точно заявленному проценту. TypeScript не улучшает и не объединяет в себе все существующие практики хорошего кода. Мне все еще приходится писать уйму тестов. Вы могли бы поспорить, что я пишу больше кода, поэтому мне и приходится писать так много тестов. Я продолжаю получать много неожиданных runtime error.
TypeScript предлагает только базовую проверку типов, а то, что надежность и проверка типов во время выполнения не входит в его цели, оставляет TypeScript в мире полумер, на полпути между лучшим миром и тем, в котором мы кодим сейчас.
TypeScript прекрасен благодаря хорошей поддержке IDE, таких как vscode, где мы получаем визуальную обратную связь в процессе печати.
Ошибка TypeScript в vscode
TypeScript также улучшает рефакторинг и ломающие код изменения (такие как изменения в сигнатурах методов) мгновенно идентифицируются при запуске компилятора TypeScript.
TypeScript предоставляет хорошую проверку типов и определенно это лучше, чем никакой проверки или простой eslint, но я чувствую, что TypeScript может быть намного лучше и необходимые опции компилятора могли бы порадовать тех, кто хочет от языка большего.
Мысли вслух о TypeScript
Прошло уже некоторое время, как я впервые познакомился и подружился с TypeScript. В те времена версия еще не перевалила за единицу. А недавно вышел релиз 1.7. За это время мы привыкли друг к другу и пережили много успехов и разочарований. Мне хочется немного поделиться своими впечатлениями и размышлениями по поводу этого диалекта JavaScript как самостоятельного языка. Идея подобного поста возникла у меня спонтанно при обсуждении очередного холивара с коллегами.
Итак, что же такое собственно TypeScript — наверно уже ни для кого не секрет. Но все же, хочу упомянуть, что это попытка Microsoft принести в JavaScript статическую типизацию. Примеры кода и задачи, которые он позволяет решать, можно посмотреть на официальном сайте или здесь на хабре, благо статей написано уже не мало. На хабре уже есть статья подобного рода TypeScript: общие впечатления, поэтому, чтобы не повторяться, я решил выделить плюсы и минусы работы с языком, опираясь на свой личный опыт. Вспомнить и перечислить плюсы и минусы языка оказалось довольно непросто.
Популярность языка
Проект TypeScript создан компанией Microsoft. Фактически его создателем является Аннерс Хейлсберг. Практически с самого начала TypeScript стал быстро набирать популярность в силу своей гибкости и производительности. Немало проектов, которые были написаны на JavaScript, стали переноситься на TypeScript. Рост интереса к этому языка вызван еще и тем, что ряд идей, которые в нем реализованы, в последующем стали частью нового стандарта JavaScript. Все больше проектов переписывается на этом языке, включая такие крупные как Angular 2.0 и vscode.
Цитаты авторитетных людей
TypeScript, возможно, один из лучших JavaScript языков на фронтенде. Код, который он генерирует, выглядит наиболее привлекательно. И я думаю, что он способен снять нагрузку со стандарта ECMAScript по реализации таких вещей, как декларации и классы. Андерс показал, что этот функционал хорошо поддерживается препроцессором, поэтому нет необходимости изменять основной язык.
Я считаю, что свободная типизация в JavaScript — это одно из достоинств языка и проверка типов переоценена. TypeScript добавляет удобства слишком дорогой ценой. И эта не та цена, за которую я готов платить.
Для пользователей Visual Studio — TypeScript довольно хороший инструмент для разработки, и к тому же он отлично соответствует стандарту ES6. Я бы мог больше рассказать об этом языке, но не вижу смысла сравнивать его с Dart.
Я огромный поклонник CoffeeScript хотя это и другой язык с самостоятельным синтаксисом. Что мне нравится в TypeScript — так это то, что статическая типизация позволяет обеспечить процесс компиляции с предупреждениями, умный рефакторинг кода. В дополнение к этому вы получаете легкую навигацию по коду. В текущей версии CoffeScript вы не получите таких возможностей.
Скотт Хансельман — евангелист Microsoft. Оригинал
Плюсы
О плюсах TypeScript написано довольно много. Поэтому постараемся тезисно отметить его преимущества:
Минусы
Как мне кажется, что в большинстве случаев TypeScript хвалят. Поэтому мне хотелось написать свой пост о том, что же не так в Typescript. И как оказалось, найти минусы было довольно не просто.
Немного о статической типизации
В жизни каждого разработчика бывает время, когда он пишет код в свое удовольствие. Будь это домашний проект, или работа в команде над проектом, который только начали писать с нуля. Это один из прекрасных моментов, когда не приходится много думать о конфликтах в коде с коллегами и искать ошибки. Но проект растет, обрастает новым функционалом и багами, связанными в том числе и с типами, если вы пишете свой код на динамически типизированном языке, коим является JavaScript.
Какое может быть решение в этом случае? Писать тесты!
Но согласитесь, зачем проверять то, с чем чем хорошо может справиться машина еще на стадии компиляции? Языки со статической типизацией избавляют нас от излишнего написания дополнительных тестов, которые связаны с ошибками в типах. Поэтому TypeScript имеет большое преимущество перед JavaScript, если мы не игнорируем типы.
Рассмотрим простой пример
У нас есть функция, которая умеет складывает два числа:
Ваш заказчик предложил реализовать веб форму, в которой бы пользователь мог вводить складываемые числа:
Пишем в наши поля ввода два числа, 2 и 3 и проверяем работу нашей функции:
Результат получился довольно неожиданный. Всё дело в том, что поле value у html-тега input возвращает результат типа «string» и JavaScript склеивает две строки «1» и «2» вместо того, чтобы сложить эти числа.
Пример, конечно довольно простой, но в реальной жизни ошибки могут быть и сложнее, и их бывает довольно трудно заметить на стадии разработки.
Решение подобной задачи довольно легко решается с помощью TypeScript:
Уже на этапе компиляции мы смогли обнаружить ошибку. Тратить силы лучше на разработку, а не на поиск ошибки и написания дополнительных тестов.
Вывод
Когда я думал над плюсами и минусами разработки на TypeScript, выделить минусы оказалось не просто. TypeScript больше оправдывает себя в крупных проектах. Это связано с тем, что разработка на нем занимает больше времени чем на JavaScript, из-за того что приходится помимо методов и классов описывать и их декларации. Но тем не менее, пока в JavaScript нет статической типизации, TypeScript является отличной альтернативой.
Чем хорош (и чем плох) Typescript: опыт UI-разработчиков
Здравствуйте, меня зовут Александр Черников. Я руковожу разработкой UI проекта “Цифровой корпоративный банк” — обновлённой версии Сбербанк Бизнес Онлайн, интернет-банка для юридических лиц. Мы разрабатываем stand-alone клиент, мобильное приложение и, собственно, web-клиент, о котором и пойдёт речь. В своих статьях я буду делиться ценным опытом нашей команды, а конкретно в этом посте опишу наш технологический стек и остановлюсь на том, почему мы выбрали Typescript в качестве основного языка.
Новую версию Сбербанк Бизнес Онлайн мы пишем 2,5 года. Уже в следующем году мы планируем перевести на него всех корпоративных клиентов Сбербанка.
Итак, начнем со стека. Мы внедрили TypeScript, React, Reflux(legacy), Redux, Bluebird Promise и Bootstrap. Стили пишем на LESS. Все это добро мы собираем с помощью Babel, Webpack и его плагинов. Webpack пока первой версии, но собираемся перейти на вторую. Многие могут спросить: зачем нам Typescript и Babel одновременно? Во-первых, раньше TypeScript не все умел транспилировать, и только недавно сравнялся с Babel по этой функциональности. Во-вторых, TypeScript не умеет кэшировать. А babel умеет хранить готовые ES5 скрипты в папке. Если исходники не поменялись, он сразу берет их оттуда. Когда проект собирается несколько минут, такая экономия времени очень радует.
Стек технологий достаточно свежий. Ребятам приходится вникать сразу в несколько вещей: например, в TS, React, Redux, в сам проект и в термины нашего банка. Из 50-60 человек только 20 процентов работают в штате, остальные подключаются от вендоров и часто меняются.
Как мы справляемся в таких условиях с code-review? Раньше несколько самых опытных разработчиков смотрели код всех команд, была такая небольшая пирамида. Сейчас мы стараемся равномерно распределить по командам. Во многих командах появились так называемые эксперты (хорошо разбираются в проекте, знают, что и где лежит), чтобы не изобретали велосипеды и прочее. Соответственно они review’ят не только ребят из своей команды, но и из других.
TypeScript и JavaScript
Я застал тот момент, когда многие писали на TS и использовали новые фичи, которые транспилируются в ES5. Но даже тогда мы использовали TS для типизации, для некоего статического анализа кода на ошибки. Да, на JS можно написать код грамотно и правильно, но он тебя не подстрахует так, как TS. Кто-то ставит в минусы, что приходится много писать TS-кода (overhead), т.е. типизация, типы, интерфейсы и др. Когда мы рефакторили “старый” код JS > TS, то выявлялись элементарные ошибки, которые сработают только в runtime. То запятая не там стоит, то точку забыли, то скобки рано закрыли и т.д., не говоря уже про недосягаемый код и неиспользуемые аргументы и пр… Когда система большая и команда не может покрыть всю систему тестами, то TS спасает. При 3000-4000 скриптах вообще трудно представить, как жить без TS.
Конечно, когда мы пишем код на JavaScript, то можем помочь компилятору и писать код, словно у нас типизированный язык: не переопределять переменные, не записывать в них разные типы, возвращать всегда один и тот же тип. Возникает вопрос: если при этом использовать babel.js, есть ли в таком случае смысл в изучении TypeScript?
Мы часто спорим по этому поводу. Некоторые коллеги говорят: “А зачем нам TS? Мы пишем код грамотно и проводим тщательно code-review, отбираем людей на собеседовании, да и вообще джедаи JS”. Но ведь человеческие факторы никто не отменял: лень, торопливость, невнимательность. Ничего не мешает подключить TS к вашему JS-коду. Если у вас действительно нет ни одной ошибки, то компилятор ничего не найдет — можете радоваться тому, что у вас отличная команда, и звезды сложились как надо. Но перестраховаться с помощью TS все равно не мешает. Тем более, что и особых затрат это не потребует.
К тому же, в этом году в версии 1.8 в TS сделали удобную фичу. Теперь можно проверить типы в чистом JS — достаточно добавить файлы “.js” в проект и allowJs флаг. Если есть какой-то код, который не хотите проверять, то спокойно его можно игнорировать через аннотацию @ts-nocheck. Во время code-review мелкие баги отловить почти нереально, а TS помогает экономить силы и время. А не то подольешь релизную ветку в develop с конфликтами в 100 файлах… хотел бы я посмотреть, как человек хладнокровно нажмет кнопку MERGE.
TypeScript vs Flow
“А как насчет Flow?” — спросите вы. Мы выбирали между ES6 и Typescript, про Flow тогда никто не знал. Для тех кому интересно, в чем разница их статического анализа кода, могу посоветовать интересный доклад Ильи Климова с конференции HolyJS 2017 Piter, где он сравнивает TypeScript и Flow.
Ложки дегтя
Помимо overhead у Typescript есть еще несколько недостатков: