Прочитал интересную историю переезда с Angular на Preact от Джорджа Фу — "Optimizing for the mobile web: Moving from Angular to Preact".

У ребят было приложение с 200 тысячими строк. Время загрузки страницы на мобильных устройствах занимало до 11 секунд. Время старта приложения в режиме разработки — 3 минуты.

Команда решила, что с этим надо что-то делать и для начала избавилась от больших библиотек: moment, lodash и core-js. После этого начался перевод листовых Angular-компонентов. Для интеропа с ангуляром был использован специальный компонент "angular-preact-bridge". Это позволило не останавливать разработку и переводить проект на Preact постепенно. В процессе переезда им очень помогал TypeScript. После всей работы (в статье не говорится о количестве затраченного времени, но у них был дедлайн в 4 месяца), размер приложения уменьшился в два раза, время загрузки снизилось до 3-4 секунд.

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

#jsframeworks #experience #migration

https://bytes.grubhub.com/optimizing-for-the-mobile-web-moving-from-angular-to-preact-f09ca61ea27c#8f83

Сегодня на хабре появилась статья Александра Воронянского про опыт модернизации фронта Маркета — "Как переписать фронтенд нагруженного проекта и не потерять главного".

Очень интересно было почитать статью, так как я непосредственно участвовал в описанных событиях. Изначально Маркет работал на xml-based технологиях. Серверная часть фронтенда обслуживалась xscript — технологией Яндекса, практически вышедшей из употребления в компании. Представьте, что если бы вы писали node.js приложение, но с помощью xml со вставками на JavaScript. Примерно так выглядела работа с xscript. Сейчас серверный фронт работает на Node.js, на клиенте используется React.

Маркет — это большой проект, который нельзя было заморозить для перевода на новый стек. Перенос осуществлялся постранично. Чтобы не просадить производительность, был настроен сбор клиентских метрик, которые показывали деградации в миграции. В конце статьи есть несколько советов по миграции больших проектов.

В общем, интересная и полезная статья. Почитайте, если у вас планируется что-то подобное.

#yandex #experience #migration

https://habr.com/ru/company/yandex/blog/486146/

Гари Бернхардт — автор проекта destroyallsoftware (и знаменитого доклада "Wat") — опубликовал серию статей про миграцию своего стартапа с JS и Ruby на TypeScript.

В первой статье "Porting a React Frontend to TypeScript" он пишет про миграцию фронтенд-кода. Добавление типов позволило статически проверять генерацию ссылок для роутера и кода, работающего с ответом из api.

Вторая статья "Porting to TypeScript Solved Our API Woes" рассказывает про миграцию Ruby-проекта на TypeScript. Один из главных плюсов перехода — статическая проверка api-хендлеров и упрощение масштабного рефакторинга. Немного рассказывается про кодогенерацию с помощью библиотеки schemats, которая по структуре базы данных генерирует d.ts-файлы сущностей предметной области.

В статье "Are Tests Necessary in TypeScript?" разбирается вопрос, нужен ли TS для проекта с большим покрытием тестами. Основная мысль — использование TS позволяет избавиться от целого класса тестов, которые необходимы в JS-коде. Тесты, в случае Гари, покрывают логику только очень важных подсистем: биллинг, управление подпиской.

Последняя статья "Problems With TypeScript in 2020" рассказывает про проблемы TypeScript. Есть баги с вотчингом файлов — могут возникать фантомные ошибки, когда из проекта удаляются файлы или добавляются новые. Редко бывают проблемы с внешними библиотеками, типы для которых поддерживаются сообществом. Но в целом, все известные минусы перекрываются преимуществами.

Рекомендую почитать статьи всем, кто задумывается о переходе на TypeScript.

#typescript #migration

Дилан Ванн написал статью про подход к миграции большого проекта на TypeScript — "How to Incrementally Migrate 100k Lines of Code to TypeScript".

Основная идея статьи — использование снапшотов ошибок компиляции для помощи в миграции. У всех js-файлов расширение меняется на ts, запускается компиляция. Все ошибки компиляции собираются в объект, с которого снимается снапшот с помощью toMatchSnapshot и записывается в файл. Этот файл попадает в систему контроля версий и становится отправной точкой для улучшения типизации проекта — каждый новый пулл реквест не должен увеличивать количество ошибок в этом файле.

Подобный подход можно применять не только с TypeScript, но и c Flow, ESLint.

Статья небольшая, но полезная. Стоит прочитать, если думаете о переводе своего проекта на TypeScript.

#typescript #migration

https://dylanvann.com/incrementally-migrating-to-typescript/

Тим Ван Дер Лип из команды разработки Chrome написал статью о миграции кодовой базы девтулзов на ECMAScript Modules — "DevTools architecture refresh: Migrating to JavaScript modules".

Chrome DevTools — это большое приложение, написанное на стандартных web-технологиях: HTML, CSS, JS. Оно было спроектировано более 10 лет назад до массового распространения модульных систем. Для организации модульности до 2020 года в Dev Tools использовался паттерн Externally Defined Dependencies. В этом паттерне весь граф зависимостей описывается в независимом файле или файлах. Специальная утилита (в случае Dev Tools, написанная на python) считывает этот файл и собирает из большого количества js-файлов один бандл.

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

Чтобы избавиться от этих проблем, ребята решили перенести всю кодовую базу на ESM. Начальная оценка была 2-4 недели, но весь процесс миграции занял 7 месяцев, так как по ходу дела возникло много проблем, например, с интеграцией со старой системой и с тестами, которые работали в sloppy режиме (то есть без "use strict"; ). Миграция включала в себя два этапа: в первом были добавлены новые export'ы, во втором — import'ы с удалением устаревшего кода.

Очень интересная статья. Советую почитать, если хотите узнать больше технических подробностей.

#esm #migration

https://developers.google.com/web/updates/2020/09/migrating-to-js-modules

Сергей Руденко из Airbnb написал статью про миграцию кодовой базы фррнтенда компании с JavaScript на TypeScript — "ts-migrate: A Tool for Migrating to TypeScript at Scale".

Для миграции они разработали инструмент ts-migrate, который помогает в массовой конвертации JavaScript файлов. Для автоматического поиска проблемных мест в коде и запуска необходимых трансформаций используются диагностики TypeScript language server. Трансформации представляют собой кодмоды, которые могут использовать jscodeshift, AST TypeScript или могут работать с исходным кодом как с обычным текстом. Есть трансформации для упрощения миграции на TypeScript React-компонентов, но без поддержки хуков.

Благодаря ts-migrate в Airbnb на TypeScript было переведено более 80% всей кодовой базы фронтенда (6 миллионов строк кода). Но так как утилита устанавливает any в проблемных местах, у ребят осталось ещё много работы над добавлением полноценных типов.

Рекомендую почитать статью, если планируете перевести код своего проекта на TypeScript.

#typescript #migration #tool

https://medium.com/airbnb-engineering/ts-migrate-a-tool-for-migrating-to-typescript-at-scale-cd23bfeb5cc

Инженеры Quip написали две статьи про опыт миграции большого проекта на TypeScript — "The Road to TypeScript at Quip".

Рассматривалось несколько вариантов миграция проекта на TypeScript. Постепенный перенос кода не подходил, так как это бы повлекло за собой много проблем. Разработчики в итоге решили сделать несколько "больших взрывов" для обновления кода. Сначала нужно было перевести код на нативную модульную систему, потом сконвертировать React.createClass в нативные классы, а затем перевести весь код на TypeScript.

Исходная кодовая база Quip была покрыта типами Google Closure Compiler. Для конвертирования этих типов можно было воспользоваться утилитой Gents от Google, но он не подходил, так как в проекте использовался специфичный синтаксис, поэтому нужно было написать свой конвертер.

Процесс перехода был удачен. За три месяца были исправлены все основные ошибки типизации. Сейчас ребята включили --strict режим компиляции, и ошибки снова появились, но ничего критично они не выявили.

Очень интересные статьи. Рекомендую почитать всем, кто задумывается о переводе своей кодовой базы на TypeScript.

#typescript #migration

https://quip.com/blog/the-road-to-typescript-at-quip-part-one
https://quip.com/blog/the-road-to-typescript-at-quip-part-two

Роб Палмер из Bloomberg рассказал об опыте использования TypeScript с огромной кодовой базой — "10 Insights from Adopting TypeScript at Scale".

В статье рассказывается о наиболее интересных вызовах, которые решала команда, занимающаяся разработкой инфраструктуры. Вот некоторые из них: динамическая генерация и использование универсального tsconfig для разных проектов, работа с зависимостями, дедупликация типов, гарантирование энкапсуляции приватных интерфейсов, решение проблем с инлайном типов в сгенерированных декларациях.

TypeScript в Bloomberg используется как "JavaScript с типами", то есть без использования фич, которые не были стандартизированы TC39 (декораторы, enum, namespace и т.п.) Такой подход значительно облегчает дебаг сгенерированного JavaScript-кода и оставляет возможность для работы с JS-движками (задел на будущее), которые смогут отбрасывать типы и запускать TypeScript-код без предварительной компиляции.

Очень большая и крутая статья. Рекомендую почитать всем, кто работает с TypeScript.

#typescript #migration

https://www.techatbloomberg.com/blog/10-insights-adopting-typescript-at-scale/

Тим Ван Дер Лип из команды разработки Chrome написал статью о миграции DevTools на TypeScript — "DevTools architecture refresh: migrating DevTools to TypeScript".

Кодовой базе Chrome DevTools уже более 10 лет. За это время она выросла до 150 тысяч строк кода и пережила несколько больших изменений. Например, в 2013 году в ней стал использоваться Closure Compiler в качестве тайпчекера. Но в 2019 году было решено отказаться от Closure в пользу TypeScript, так как Closure не обеспечивал должный уровень типобезопасности.

Автоматизировать миграцию не получилось, поэтому весь процесс занял 13 месяцев. Для распараллеливания работы между инженерами во все файлы был добавлен @ts-nocheck; процесс тайпскрификации заключался в постепенном удалении этих директив.

Разработчики остались довольны результатом. Единственная проблема, с которой пока не удалось справиться, — увеличившееся время сборки.

#typescript #migration

https://developer.chrome.com/blog/migrating-to-typescript/

Новая CSS-инфраструктура Chrome DevTools

Крити Сапра написала статью про обновлённый подход подключения CSS в кодовой базе Chrome DevTools — "Modernising CSS infrastructure in DevTools".

В кодовой базе DevTools очень долгое время использовалась устаревшая модульная система. С её помощью происходило разрешение зависимостей между JS-файлами и подключение CSS. При переходе на TypeScript возник вопрос отказа от старой модульной системы и миграции существующих стилей. Самым подходящим вариантом стала автоматическая конвертация стилей в JS-файлы, которые экспортируют объект CSSStyleSheet. Таким образом из любого сконвертированного файла можно импортировать стили и применить их к веб-компонентам с помощью adoptedStyleSheets.

Такое решение позволило избавиться от проблемы дублирования стилей, от потенциальной коллизии названия классов и подготовило код для дальнейшей миграции на CSS Module Scripts. В статье также говорится о том, что сама спецификация CSS Module Scripts родилась из задачи обновления модульной системы в DevTools.

#css #migration #chrome

https://developer.chrome.com/blog/modernising-css-infra-in-devtools/