Эффективный TypeScript: 83 способа улучшить код E-Book

Дэн Вандеркам

• Herausgeber: Спринт Бук
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Russisch

Seitenzahl: 507

Veröffentlichungsjahr: 2025

Beschreibung

Способен ли TypeScript устранить проблемы, которыми так знаменит JavaScript? Да, но его изучение потребует определенных усилий, времени и практики. 83 правила позволят ускорить и облегчить знакомство с TypeScript. Каждое правило — это конкретная рекомендация, рассказывающая на примерах что можно и чего нельзя делать в TypeScript и как грамотно работать с этим языком. Эта книга поможет подняться с уровня начинающего или среднего пользователя, знакомого с основами TypeScript, на уровень TS-эксперта, который может профессионально работать с этим языком. Второе издание было обновлено для TypeScript 5, и включает две новые главы, посвященные программированию на уровне типов и рецептам TypeScript.

Leseprobe

Переводчики Е. Матвеев, Е. Матвеев

Дэн Вандеркам

Эффективный TypeScript: 83 способа улучшить код. 2-е изд. . — Астана: "Спринт Бук", 2025.

ISBN 978-601-08-4572-5

© ТОО "Спринт Бук", 2025

Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

Оглавление

Отзывы

Посвящение

Введение ко второму изданию

Для кого эта книга

Почему я написал эту книгу

Структура книги

Условные обозначения в примерах кода

Типографские соглашения

Использование примеров кода

Благодарности

Введение к первому изданию (2019)

Благодарности к первому изданию

От издательства

Глава 1. Знакомство с TypeScript

Правило 1. Разберитесь, как TypeScript связан с JavaScript

Правило 2. Выбирайте нужные опции в TypeScript

Правило 3. Помните, что генерация кода не зависит от типов

Правило 4. Привыкайте к структурной типизации

Правило 5. Ограничьте применение типа any

Глава 2. Система типов в TypeScript

Правило 6. Используйте редактор для получения информации о системе типов

Правило 7. Воспринимайте типы как множества значений

Правило 8. Правильно выражайте принадлежность сущностей к пространству типов или пространству значений

Правило 9. Отдавайте предпочтение аннотациям типов, а не утверждениям

Правило 10. Избегайте объектных типов-оберток (String, Number, Boolean, Symbol, BigInt)

Правило 11. Отличайте проверку лишних свойств от проверки типов

Правило 12. По возможности применяйте типы ко всему функциональному выражению

Правило 13. Знайте различия между type и interface

Правило 14. Используйте readonly для предотвращения ошибок, связанных с изменяемостью

Правило 15. Используйте операции типов и обобщения для предотвращения повторов

Правило 16. Используйте более точные альтернативы для сигнатур индексов

Правило 17. Избегайте использования числовых сигнатур индексов

Глава 3. Вывод типов и анализ потока управления

Правило 18. Не засоряйте код лишними аннотациями типов

Правило 19. Используйте разные переменные для разных типов

Правило 20. Разберитесь в процессе расширения типов

Правило 21. Создавайте объекты целиком

Правило 22. Освойте сужение типов

Правило 23. Будьте последовательны с использованием псевдонимов

Правило 24. Используйте контекст при выводе типов

Правило 25. Разберитесь с эволюционирующими типами

Правило 26. Используйте функциональные конструкции и библиотеки для улучшения работы с типами

Правило 27. Для асинхронного кода используйте async-функции вместо обратных вызовов

Правило 28. Используйте классы и каррирование для создания новых точек вывода типов

Глава 4. Проектирование типов

Правило 29: Используйте типы, всегда представляющие допустимые состояния

Правило 30. Будьте консервативны в том, что отправляете, и либеральны в том, что принимаете

Правило 31. Не повторяйте информацию типа в документации

Правило 32: Избегайте включения null или undefined в псевдонимы типов

Правило 33. Выносите null на периферию типов

Правило 34. Отдавайте предпочтение объединениям интерфейсов, а не интерфейсам с объединениями

Правило 35. Вместо string используйте более узкие типы

Правило 36. Используйте отдельный тип для специальных значений

Правило 37. Ограничьте использование опциональных свойств

Правило 38. Избегайте повторяющихся параметров одного типа

Правило 39. Стремитесь к унификации типов, а не к моделированию различий

Правило 40. Лучше сделать тип неточным, чем недостоверным

Правило 41. Назначайте имена типов на языке предметной области задачи

Правило 42. Генерируйте типы на основе API и спецификаций, а не данных

Глава 5. Ненадежность и тип any

Правило 43. Используйте максимально узкий диапазон для типов any

Правило 44. Используйте более точные варианты any

Правило 45. Скрывайте небезопасные утверждения типов в хорошо типизированных функциях

Правило 46. Используйте unknown вместо any для значений с неизвестным типом

Правило 47. Используйте типобезопасные решения вместо динамической модификации

Правило 48. Избегайте ловушек надежности

Правило 49. Отслеживайте зону охвата типов для предотвращения регрессии в типобезопасности

Глава 6. Обобщения (дженерики) и программирование на уровне типов

Правило 50. Рассматривайте обобщения (дженерики) как функции между типами

Правило 51. Избегайте лишних параметров типа

Правило 52. Лучше условные типы, чем перегруженные сигнатуры

Правило 53. Научитесь управлять распределением объединений с условными типами

Правило 54. Используйте шаблонные литеральные типы для моделирования DSL и отношений между строками

Правило 55. Пишите тесты для своих типов

Правило 56. Обращайте внимание на отображение типов

Правило 57. Отдавайте предпочтение обобщенным типам с хвостовой рекурсией

Правило 58. Рассмотрите кодогенерацию в качестве альтернативы для сложных типов

Глава 7. Рецепты TypeScript

Правило 59. Используйте типы never для выполнения проверки полноты

Правило 60. Разберитесь, как итерировать по объектам

Правило 61. Используйте типы записей для поддержания синхронизации значений

Правило 62. Используйте остаточные параметры и типы кортежа для моделирования функций с переменным числом аргументов

Правило 63. Используйте опциональные свойства never для моделирования исключающего ИЛИ

Правило 64. Рассмотрите применение маркировок для номинальной типизации

Глава 8. Объявления типов и @types

Правило 65. Размещайте TypeScript и @types в devDependencies

Правило 66. Проверяйте совместимость трех версий, задействованных в объявлениях типов

Правило 67. Экспортируйте все типы, появляющиеся в открытых API

Правило 68. Используйте TSDoc для комментариев к API

Правило 69. Определяйте тип this в обратных вызовах, если он является частью API

Правило 70. Зеркалируйте типы для разрыва зависимостей

Правило 71. Используйте аугментацию модулей для улучшения типов

Глава 9. Написание и запуск кода

Правило 72. Отдавайте предпочтение функциональности ECMAScript перед TypeScript

Правило 73. Используйте Source Map для отладки TypeScript

Правило 74. Научитесь реконструировать типы на стадии выполнения

Правило 75. Разберитесь с иерархией DOM

Правило 76. Создайте точную модель среды выполнения

Правило 77. Понимайте связь между проверкой типов и юнит-тестированием

Правило 78. Уделяйте внимание быстродействию компилятора

Глава 10. Модернизация и миграция

Правило 79. Пишите современный JavaScript

Правило 80. Используйте @ts-check и JSDoc для экспериментов в TypeScript

Правило 81. Используйте allowJs для совмещения TypeScript и JavaScript

Правило 82. Конвертируйте модуль за модулем вверх по графу зависимостей

Правило 83. Не считайте миграцию завершенной, пока не включите noImplicitAny

Приложение А. Соответствие правил в двух изданиях книги

Об авторе

Иллюстрация на обложке

Рекомендуем прочитать

Отзывы

«В книге “Эффективный TypeScript” автор рассматривает распространенные проблемы, с которыми мы сталкиваемся при работе с TypeScript, и дает практические советы, ориентированные на достижение результата. Книга пригодится и опытным, и начинающим разработчикам».

Райан Кавано, ведущий инженер по TypeScript в Microsoft

«Второе издание “Эффективного TypeScript” — отличное дополнение к и без того превосходной книге. Практичные советы из первого издания сочетаются в нем с рекомендациями по лучшим практикам TypeScript. Приведенная информация крайне необходима для работы с TypeScript в проектах любого размера. Мне особенно понравилось, что во многих рекомендациях описаны нюансы того, когда и почему они должны применяться. Советую каждому разработчику, кто хочет глубоко освоить написание кода TypeScript, перечитать эту книгу не один раз и делать подробные заметки».

Джош Голдберг, участник сообщества разработки с открытым кодом, автор книги «Learning TypeScript»

«“Эффективный TypeScript” — не просто руководство по одному из самых по­пулярных языков программирования в мире. Книга научит вас мыслить категориями типов, дополняя это практическими советами по их применению. Опыт Дэна проявляется на каждой странице. Эта книга для сильных духом! И она может изменить ваши представления о программировании за пределами TypeScript».

Стефан Баумгартнер, старший архитектор продукта, Dynatrace, автор книги «TypeScript Cookbook»1

«Второе издание “Эффективного TypeScript” — превосходная книга для инженеров, которые уже знакомы с азами TypeScript, пишут на нем в рамках своей повсе­дневной работы или размышляют о миграции на TypeScript своей кодовой базы».

Борис Черный, автор книги «Programming TypeScript»2

«Я работала с TypeScript более 10 лет как в области преподавания, так и в профессиональной практике. “Эффективный TypeScript” предлагает дельные советы, которые хорошо согласуются с моим опытом. Книга убедительно показывает, что понимание синтаксиса TypeScript — одно, а умение пользоваться его возможностями — совсем другое. Это полезное руководство для тех, кто знаком с TypeScript, но хочет научиться использовать его возможности на новом уровне».

Титиан-Корнел Черникова-Драгомир, разработчик из Bloomberg LP

«“Эффективный TypeScript” содержит практические рецепты: эта книга должна быть под рукой у каждого профессионального разработчика. Даже если вы думаете, что знаете TypeScript, купите эту книгу — не пожалеете».

Яков Файн, Java-чемпион

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

Джесси Халлетт, сеньор инженер-разработчик, Hasura

1 Баумгартнер С. «Рецепты Typescript». СПб., издательство «Питер».

2 Черный Б. «Профессиональный TypeScript». СПб., издательство «Питер».

Посвящается Алекс.

Ты — мой идеал.

Благодарности

Вопреки моим надеждам, работа над вторым изданием была не проще и не быстрее, чем над первым. При этом книга увеличилась с 62 правил до 83. Кроме написания 22 новых правил (одно старое правило было интегрировано с другим), я проанализировал и тщательно пересмотрел весь исходный материал. Некоторые части, например правила 45 и 55, были практически полностью переписаны.

Многие новые правила основаны на материале, который впервые был опубликован в блоге «Effective TypeScript» (https://effectivetypescript.com), хотя все они сильно переработаны.

Глава 6 в основном написана по моему личному опыту построения библиотек crosswalk (https://oreil.ly/-XQ6A) и crudely-typed (https://oreil.ly/E7_gV) для Delve в Sidewalk Labs.

Кратко перечислю источники правил для второго издания.

• Правило 28 адаптировано по материалам поста в блоге «Use Classes and Cur­rying to Create New Inference Sites» («Использование классов и каррирования для создания новых точек вывода типов») (https://oreil.ly/OAApn).

• Правило 32 возникло в результате ряда код-ревью. Я и не знал, что это правило, пока не увидел, как оно нарушается.

• Правило 36 возникло из обратной связи, которую я предоставлял по бесчисленным код-ревью.

• Правило 37 основано на личном опыте и посте «Why Not Add an Option for That» («Почему бы не добавить для этого опцию?») в блоге Эвана Мартина (Evan Martin) (https://oreil.ly/YJWQR). Твиты Кори Хауза (Cory House) по этой теме помогли мне набраться храбрости для включения материала в книгу.

• Правило 38 вдохновлено цитатой Алана Перлиса (Alan Perlis), которую я часто привожу, а также правилом Скотта Мейерса.

• Правило 39 основано на опыте работы моей команды с адаптером Jsonify, который мы с большой радостью приняли и от которого потом с еще большей радостью избавились. Этот опыт привел к появлению поста «The Trouble with Jsonify: Unify Types Instead of Modeling Small Differences» («Проблемы с Jsonify: объединяйте типы вместо моделирования мелких различий») (https://oreil.ly/zVod4).

• Правило 48 адаптировано по материалам поста «The Seven Sources of Unsoundness in TypeScript» («Семь источников ненадежности в TypeScript») (https://oreil.ly/NiTnr) со значительным творческим участием Райана Кавано (Ryan Cavanaugh).

• Правило 50 появилось в результате размышлений относительно того, что собой представляют типы, и благодаря ответу с объяснением зависимых типов на Stack Overflow.

• Правило 51 представляет собой адаптацию поста «The Golden Rule of Generics» («Золотое правило обобщений») (https://oreil.ly/yaxs8), которое, в свою очередь, является адаптированной версией совета из учебника TypeScript.

• Правило 53 вдохновлено моей работой над crosswalk и crudely-typed, а также моим любопытством по поводу всех оберток [T], которые я видел.

• В основу правила 54 легли мои исследования типов шаблонных литералов после выхода TypeScript 4.1, приведших к появлению поста «TypeScript Splits the Atom!» («TypeScript расщепляет атом!») (https://oreil.ly/Es6Ep).

• Правило 56 стало результатом моего длительного интереса к этой теме. Все началось с ответа Титиан Черниковой-Драгомир на вопрос о типизации _.invert на Stack Overflow, за ним последовали мои выводы по работе над crosswalk и crudely-typed, и все в итоге завершилось постом «The Display of Types» («Представление типов») (https://oreil.ly/bue9Q).

• Правило 57 вдохновлено примечаниями к релизу TypeScript 4.5, в котором добавилась хвостовая рекурсия.

• Правило 58 основано на моем опыте связывания TypeScript с базами данных, что в итоге привело меня к докладу на Конгрессе TypeScript 2022 года: «TypeScript and SQL: Six Ways to Bridge the Divide» («TypeScript и SQL: шесть способов преодоления разрыва») (https://oreil.ly/ofuph).

• В правиле 589 представлен трюк, с которым меня познакомил Джесси Халлен (Jesse Hallett) во время рецензирования первого издания. Разновидность с парами была предложена в твите Тома Хикса (Tom Hicks) от 2021 года.

• Правило 62 вдохновлено постом в блоге Artsy: «“Conditional Types in TypeScript» («Условные типы в TypeScript») (https://oreil.ly/r-7E0).

• Правило 63 возникло из обратной связи по первому изданию, полученной от Райана Кавано, которую я в итоге преобразовал в пост в блоге: «Exclusive Or and the Optional never Trick» («Исключающее ИЛИ, или прием с опциональным never») (https://oreil.ly/os01S). Энтузиазм Штефана Баумгартнера (Stefan Baumgartner) по поводу этого приема в книге «TypeScript Cookbook» (O'Reilly) заставил меня включить его описание в свою книгу.

• Правило 71 вдохновлено дискуссией с Эваном Мартином на Reddit и неприятной ошибкой, прокравшейся в newSet("string"). Она привела к посту в блоге «In Defense of Interface: Using Declaration Merging to Disable “Bad Parts”» («В защиту интерфейсов: использование слияния объявлений для отключения “нежелательных частей”») (https://oreil.ly/iYGLY).

• Тема правила 74 встречается достаточно часто, особенно у тех, у кого еще не сформировалась правильная ментальная модель TypeScript.

• Правило 76 появилось из-за бесчисленных сеансов отладки, причиной которых послужили неправильные модели среды.

• Правило 77 вдохновлено моим личным интересом к теме, несколькими вопросами на Stack Overflow и беседой с Гэри Бернхардтом (Gary Bernhardt).

• Правило 78 основано на личном неприятном опыте с замедлением работы TypeScript. Материал был основан на вики TypeScript и посте в блоге «What's Typescript Compiling? Use a Treemap to Find Out» («Что компилирует TypeScript? Древовидная карта поможет вам узнать это») (https://oreil.ly/QRilV).

Спасибо моим научным редакторам: Джошу Голдбергу, Штефану Баумгартнеру, Райану Кавано, Борису Черному и Титиан Черниковой-Драгомир. Полученная от вас обратная связь сделала эту книгу неизмеримо лучше. Спасибо моим коллегам в группе опыта взаимодействия Delve (особенно Стефани Чу (Stephanie Chew), Люде Жао (Luda Zhao), Ха Ву (Ha Vu) и Аманде Морер (Amanda Meurer)) за все рецензирование кода и за то, что они поддержали мой безграничный энтузиазм по отношению к TypeScript. Спасибо всем работникам O'Reilly, благодаря которым появилась эта книга: Анджеле Руфино (Angela Rufino), Эшли Стасси (Ashley Stussy), Аманде Куинн (Amanda Quinn), Клэр Лейлок (Clare Laylock), Соне Саруба (Sonia Saruba). Спасибо Крису Мишайкову (Chris Mischaikow) за последнюю вычитку. Плейлист Jazzy Morning на Spotify, начиная с «Beautiful Sunrise» от Arta Porting, помогал мне в написании и редактировании.

Наконец, спасибо Алекс за всю ее поддержку: во время пандемии, на свадьбе, при смене работы и большом переезде. Я рад, что хоть что-то остается неизменным!

Введение к первому изданию (2019)

Весной 2016 года я навестил своего бывшего коллегу Эвана Мартина, работавшего в офисе Google в Сан-Франциско, и поинтересовался, чем он сейчас занимается. Этот вопрос я задавал ему в разные годы и постоянно получал новые, неожиданные, но каждый раз очень интересные ответы. Он рассказывал об инструментах создания C++, аудиодрайверах Linux, скриптах для Emacs и онлайн-кроссвордах. На этот раз Эван занялся TypeScript и Visual Studio Code.

Он меня удивил. Я слышал о TypeScript, но знал только, что это разработка Microsoft, ошибочно думая, что она имеет какое-то отношение к .NET. Я не мог поверить, что Эван, который всю жизнь пользовался Linux, вдруг оценил Microsoft.

Затем он показал мне VS Code и песочницу TypeScript в деле, и я сразу же оценил происходящее: все работало очень быстро, а инструменты анализа кода легко выстраивали модель системы типов. Я много лет аннотировал типы в комментариях JSDoc для Closure Compiler и воспринял TS как реально работающий типизированный JavaScript. Неужели Microsoft разработала кросс-платформенный текстовый редактор на платформе Chromium? Возможно, этот язык с его набором инструментов действительно достоин изучения.

Я не так давно присоединился к Sidewalk Labs и начал писать первый JavaScript-проект. Кодовая база была достаточно мала, и мы с Эваном смогли конвертировать его в TypeScript всего за несколько дней.

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

Бруклин, Нью-Йорк, октябрь 2019 г.

Благодарности к первому изданию

Эта книга появилась благодаря многим людям. Спасибо Эвану Мартину за подробное знакомство с TypeScript. Доуи Осинге (Douwe Osinga) — за представление меня издательству O'Reilly и поддержку в проекте. Бретту Слаткину (Brett Slatkin) — за советы по структуре и подсказку, что среди моих знакомых есть автор «эффективной» книги. Скотту Мейерсу — за внедрение этого формата и за его полезный пост «Effective Books» («Эффективные книги») в блоге.

Моим научным редакторам: Рику Баттлайну (Rick Battagline), Райану Кавано, Борису Черному, Якову Файну (Yakov Fain), Джейсону Киллиану (Jason Killian) и Джесси Халлету. Всем моим коллегам в Sidewalk, изучавшим TypeScript со мной все эти годы. Всем сотрудникам O'Reilly, участвовавшим в создании книги: Анджеле Руфино, Дженнифер Поллок (Jennifer Pollock), Деборе Бейкер (Deborah Baker), Нику Адамсу (Nick Adams) и Джасмин Квитин (Jasmine Kwityn). Команде TypeScript NYC: Джейсону, Орте и Кириллу, а также всем спикерам. Многие правила появились благодаря обсуждениям на митапе:

• Правило 3 вдохновлено сообщением в блоге Эвана Мартина, которое показалось мне особенно содержательным, когда я только приступил к изучению TypeScript.

• Правило 7 вдохновлено докладом Андерса о структурной типизации и отношениях keyof на конференции TSConf 2018, а также докладом Джесси Халлета на TypeScript NYC Meetup в апреле 2019 года.

• Наставления Басарата (Basarat) и полезные ответы DeeV и GPicazo на сайте Stack Overflow сыграли важнейшую роль при написании правила 9.

• Правило 10 основано на аналогичном совете из правила 4 книги «Effective JavaScript».

• Я решил написать правило 11 после всеобщей путаницы по этой теме на митапе TypeScript NYC в августе 2019 года.

• Правилу 13 сильно помогли вопросы о сравнениях типов с интерфейсами на сайте Stack Overflow. Джесси Халлет предложил формулировку, основанную на расширяемости.

• Джекоб Баскин (Jacob Baskin) предоставил содействие и раннюю обратную связь по правилу 15.

• Правило 18 основано на нескольких примерах кода, опубликованных в ветке Reddit r/typescript.

• Правило 24 базировалось на моей собственной статье для Medium и материалах доклада, с которым я выступил на митапе TypeScript NYC в октябре 2019 года.

• Правило 29 основано на популярной рекомендации в Haskell («Сделайте недопустимые состояния не имеющими представления»). История о рейсе Air France 447 написана по материалам замечательной статьи Джеффа Уайза (Jeff Wise) в «Popular Mechanics» за 2011 год.

• Правило 30 описывает проблему, с которой я столкнулся при работе с объявлениями типов Mapbox. Джейсон Киллиан предложил формулировку в названии.

• Рекомендации по выбору имен в правиле 41 широко известны, но эта конкретная формулировка была вдохновлена короткой статьей Дэна Норта в книге «97 Things Every Programmer Should Know» (Kevlin, Henney, O'Reilly).

• Правило 64 вдохновлено докладом Джейсона Киллиана на первом митапе TypeScript NYC в сентябре 2017 года.

• Правило 25 основано на примечаниях к выпуску версии TypeScript 2.1. Термин «эволюция any» редко используется за пределами самого компилятора TypeScript, но мне показалось, что для этого необычного паттерна будет полезно придумать название.

• Правило 46 вдохновлено публикацией в блоге Джесси Халлета.

• Правилу 47 очень помогла обратная связь, полученная от Титиан Черниковой-Драгомир в выпуске TypeScript №33128.

• Правило 49 основано на работе Йорка Яо (York Yao) с описанием программы type-coverage. Мне было нужно что-то в этом роде, и я нашел это!

• Правило 66 основано на материалах доклада, с которым я выступил на митапе TypeScript NYC Meetup в декабре 2017 года.

• За правило 52 я должен поблагодарить Дэвида Шелдрика (David Sheldric). Его сообщение в блоге Artsy, посвященное условным типам, сняло покров тайны с этой темы.

• Правило 70 появилось благодаря докладу Стива Фолкнера (Steve Faulkner) (он же southpolesteve) на митапе в феврале 2019 года.

• Правило 55 основано на моей статье для Medium и работе над программой typings-checker, которая со временем преобразовалась в dtslint.

• Правило 72 написано по материалам статьи Кэт Буш (Kat Busch) для Medium с описаниями различных видов перечислений в TypeScript, а также изложения этой темы Борисом Черным в книге «Programming TypeScript» (O'Reilly).

• Правило 60 появилось из-за путаницы по этой теме, которая была у меня и моих коллег. Исчерпывающее объяснение было найдено Андерсом в TypeScript PR #12253.

• При написании правила 75 огромную пользу принесла документация MDN.

• Глава 10 основана на моем опыте миграции стареющей библиотеки dygraphs.

Было еще множество постов и обсуждений, большинство из которых собраны в ветке r/typescript на Reddit. Отдельную благодарность хочу выразить разработчикам, предоставившим образцы кода, которые оказались очень полезны для понимания базовых особенностей TypeScript. Спасибо Мариусу Шульцу (Marius Schulz) за рассылку «TypeScript Weekly». Пусть она выходит не каждую неделю, но всегда оказывается отличным источником информации и помогает быть в курсе последних событий TypeScript. Андерсу, Дэниэлу, Райану и всей команде TypeScript в Microsoft — спасибо за общение и отзывчивость в решении возникавших проблем. Даже в случае простых недоразумений ничто не сравнится с тем, чтобы отправить баг и увидеть, как сам Андерс Хейлсберг мгновенно его исправляет.

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

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу

[email protected]

(издательство «SprintBook», компьютерная редакция).

Мы будем рады узнать ваше мнение!