TypeScript's Migration to Modules - TypeScript
Пост в блоге Typescript про миграцию на typescript на модули.
В релиз ноутсах к релизу 5.0 команда typescript уже рассказывала, что они порефакторили кодовую базу и смогли переехать на модули и получили от этого большой (10-20%) буст в перформансе. В этой статье подробно рассказывается, как конкретно производилась миграция
Исторически так сложилось, что кодовая база Typescript писалась с использованием неймспейсов. Это привело к нескольким проблемам:
- Невозможность использовать фичи, которые разрабатываются для пользователей. Инкрементальные билды, автоматическая организация импортов и другие. Это создает ситуацию, когда разработчики typescript не могут сами оценить преимущества и проблемы того, что они создают.
- Из-за реализации неймспейсов (создание дополнительных оберток, скоупов) появляется замедление перформанса в рантайме.
Т.к. кода написано много и проводить ручной рефакторинг из неймспейсов в модули параллельно разработке (а фризить разработку на недели или месяцы никто не будет) просто невозможно, команда автоматизировала большинство кейсов миграции.
Текущий консенсус по созданию оптимизированных приложений состоит в том, чтобы использовать какой-нибудь бандлер, который умеет оптимизировать код. Поэтому разработчики typescript решили тоже бандлить свой проект. Они выбрали esbuild как за скорость и удобство, так и за умение инлайнить енамы прямо в код.
Миграция прошла одним пул-реквестом на 282к строк кода. Этот ПР постоянно обновлялся новым кодом из мастера т.к. команда не хотела фризить разработку. Автоматизация миграции позволяла достаточно быстро обновлять ветку. Автоматические тесты давали уверенность в том, что все работает как надо. Поэтому в 1 момент мастер все таки зафризили и влили 1 большой ПР. Теперь TS написан на es модулях
Что это дало:
- итоговый размер пакета уменьшился почти в 2 раза
- ускорение работы на 10-20%
- современная кодовая база
- пользователи могут работать с модулями, вместо неймспейсов, что намного удобнее
- команда ТС пользуется своими же фичами для модулей
Также в статье рассматривается кейс, когда переезд на современный код немного замедлил парсер. Дело в том, что до переезда на esbuild код собирался в ES5, и все let и const трансформировались в var. Теперь же код собирается в ES2018 и let и const остаются. Это привело к просадке скорости работы парсера на 5% т.к. JS-движку необходимо чекать в рантайме, была ли уже инициализирована переменная. Как решение - в особо чувствительных местах typescript'а используются var вместо let и const. Но вообще команда ожидает доработки в esbuild, чтобы он позволял компилировать let и const в var там, где это безопасно. А безопасность уже гарантируется typescript'ом.
https://devblogs.microsoft.com/typescript/typescripts-migration-to-modules/
#development #typescript #migration
Пост в блоге Typescript про миграцию на typescript на модули.
В релиз ноутсах к релизу 5.0 команда typescript уже рассказывала, что они порефакторили кодовую базу и смогли переехать на модули и получили от этого большой (10-20%) буст в перформансе. В этой статье подробно рассказывается, как конкретно производилась миграция
Исторически так сложилось, что кодовая база Typescript писалась с использованием неймспейсов. Это привело к нескольким проблемам:
- Невозможность использовать фичи, которые разрабатываются для пользователей. Инкрементальные билды, автоматическая организация импортов и другие. Это создает ситуацию, когда разработчики typescript не могут сами оценить преимущества и проблемы того, что они создают.
- Из-за реализации неймспейсов (создание дополнительных оберток, скоупов) появляется замедление перформанса в рантайме.
Т.к. кода написано много и проводить ручной рефакторинг из неймспейсов в модули параллельно разработке (а фризить разработку на недели или месяцы никто не будет) просто невозможно, команда автоматизировала большинство кейсов миграции.
Текущий консенсус по созданию оптимизированных приложений состоит в том, чтобы использовать какой-нибудь бандлер, который умеет оптимизировать код. Поэтому разработчики typescript решили тоже бандлить свой проект. Они выбрали esbuild как за скорость и удобство, так и за умение инлайнить енамы прямо в код.
Миграция прошла одним пул-реквестом на 282к строк кода. Этот ПР постоянно обновлялся новым кодом из мастера т.к. команда не хотела фризить разработку. Автоматизация миграции позволяла достаточно быстро обновлять ветку. Автоматические тесты давали уверенность в том, что все работает как надо. Поэтому в 1 момент мастер все таки зафризили и влили 1 большой ПР. Теперь TS написан на es модулях
Что это дало:
- итоговый размер пакета уменьшился почти в 2 раза
- ускорение работы на 10-20%
- современная кодовая база
- пользователи могут работать с модулями, вместо неймспейсов, что намного удобнее
- команда ТС пользуется своими же фичами для модулей
Также в статье рассматривается кейс, когда переезд на современный код немного замедлил парсер. Дело в том, что до переезда на esbuild код собирался в ES5, и все let и const трансформировались в var. Теперь же код собирается в ES2018 и let и const остаются. Это привело к просадке скорости работы парсера на 5% т.к. JS-движку необходимо чекать в рантайме, была ли уже инициализирована переменная. Как решение - в особо чувствительных местах typescript'а используются var вместо let и const. Но вообще команда ожидает доработки в esbuild, чтобы он позволял компилировать let и const в var там, где это безопасно. А безопасность уже гарантируется typescript'ом.
https://devblogs.microsoft.com/typescript/typescripts-migration-to-modules/
#development #typescript #migration