Материал подготовлен на основе практического опыта команды Compo Soft и посвящён развитию корпоративной платформы Compo B2B Platform — зрелого B2B‑решения, используемого десятками компаний в ежедневных бизнес‑процессах.
Это интервью — разбор реального опыта миграции фронтенда Compo B2B Platform с Angular 13 на актуальные версии фреймворка (в итоге — Angular 19). Команда Compo Soft прошла путь через несколько мажорных апдейтов, замену и переписывание зависимостей, рефакторинг архитектуры и внедрение новых возможностей Angular — от Standalone Components до Vite и non‑destructive hydration.
Ниже — честный рассказ о том, что сработало, где возникли сложности и какие выводы стоит сделать тем, кто только планирует подобное обновление. На вопросы отвечает ведущий фронтенд‑разработчик Compo Soft Дмитрий Федоренко.
Проект: какая область, сколько пользователей, клиентов, фронтенд‑архитектура?
Это B2B‑платформа, ориентированная на задачи средних и крупных предприятий.
Бэкенд написан на Java Spring, фронтенд — на Angular. Монорепозиторий фронтенда содержит два основных приложения:
административную панель;
клиентский кабинет.
Оба приложения используют общую библиотеку компонентов и утилит.
Исторически в проекте накопилось большое количество зависимостей в package.json, и именно это стало одной из ключевых проблем перед миграцией. На старте у нас был следующий набор UI‑ и вспомогательных библиотек:
Nebular;
Taiga UI;
Angular Material;
ngx‑formly;
Bootstrap CSS 4;
ngx‑easy‑table;
tslib.
Какая версия Angular использовалась до обновления?
Мы застряли на версии Angular 13.3, выпущенной весной 2022 года. На тот момент она была стабильной, поэтому мы пропустили несколько мажорных релизов с важными оптимизациями и архитектурными изменениями.
Почему вы решили обновиться именно сейчас — это был бизнес‑ или технический драйвер?
Причины лежали на стыке бизнеса и разработки.
С бизнес‑точки зрения основной запрос заключался в унификации интерфейса. Со временем один и тот же функционал начал выглядеть и работать по‑разному в разных частях приложения: кнопки, иконки, поля форм отличались от страницы к странице. Это типичная проблема большого и долго развивающегося фронтенда.
Параллельно мы исправляли устаревшие UI/UX‑решения и паттерны, которые регулярно вызывали жалобы клиентов.
С технической стороны назрела необходимость масштабного рефакторинга. Кодовая база страдала от дублирования: вместо переиспользования и наследования компонентов часто создавались копии, отличающиеся одной‑двумя строками.
Однако главной болью стала скорость разработки. Даже небольшие правки в вёрстке или логике требовали ждать 3–6 секунд, пока Ivy‑компилятор пересобирал проект. Холодный старт dev‑сервера и постоянные задержки при работе с UI делали разработку утомительной.
Именно это стало главным мотиватором перехода на актуальные версии Angular с поддержкой Vite.
Какие шаги вы предприняли перед началом миграции? Был ли аудит кода?
Мы начали с простого: создали отдельную ветку и попробовали выполнить ng update. Глубокого аудита на старте не было — и это оказалось ошибкой.
У команды не было достаточной экспертизы в подобных масштабных обновлениях, и мы не до конца понимали риски. Ключевые вопросы, на которые не было ответов:
выживут ли основные библиотеки (Nebular, Taiga UI);
удастся ли вообще собрать проект;
не проще ли начать всё с нуля.
Первая попытка обновления закончилась неудачей: проект начал «ломаться» в самых разных местах. В процессе стало очевидно несколько важных вещей.
Нужен ESLint вместо устаревшего TSLint
Мы настроили ESLint с максимальным набором правил для Angular и шаблонов. Часть правил перевели в режим warn, второстепенные — отключили. В проекте исторически было много any, и переписывать всё сразу мы не планировали, поэтому тонкая настройка линтера оказалась критичной. Среда разработки (у нас IntelliJ IDEA) должна корректно отображать ошибки линтинга в реальном времени.AOT‑компиляцию необходимо включать уже в dev‑режиме
Если этого не сделать, проект может успешно собираться, но фатальные ошибки будут возникать уже в браузере во время работы приложения.Нужно отказаться от ‑legacy‑peer‑deps
Исторически зависимости устанавливались именно с этим флагом. При обновлении Angular это привело к неразрешимым конфликтам версий. Попытки продолжить работу с legacy peer deps вызывали хаотичные и трудно воспроизводимые баги. Перед миграцией зависимости пришлось привести в порядок, даже ценой обновления второстепенных библиотек.
Какой подход использовался: big bang, поэтапная миграция, feature toggle?
Подход напрямую зависит от количества и качества внешних зависимостей.
Если библиотек немного, можно обновляться сразу до последней версии. В нашем случае это было невозможно: мы последовательно прошли через Angular 15, 17 и в итоге дошли до версии 19.
Не все сторонние библиотеки поддерживали новые версии фреймворка. Часть из них пришлось заменить на более современные open‑source‑аналоги, что‑то написать с нуля, а от некоторых устаревших решений — отказаться полностью.
Много времени заняло обновление Taiga UI с версии 2 до версии 4. API библиотеки значительно изменился: методы, помеченные как deprecated в третьей версии, были полностью удалены в четвёртой.
Также важно учитывать связку версий Angular и TypeScript. Каждая версия Angular требует определённую версию TypeScript, и она может быть несовместима с используемыми библиотеками. При миграции приходится тщательно подбирать комбинацию Angular + TypeScript + сторонние зависимости.
Мы выбрали гибридный подход, который условно можно назвать «поэтапным Big Bang»:
в основной ветке подготовили кодовую базу (обновили второстепенные зависимости, начали использовать Standalone Components в новых модулях, минимально отрефакторили проблемные места);
создали отдельную long‑lived ветку, где последовательно выполнили ng update через несколько мажорных версий;
изменения вливали в основную ветку не целиком, а логическими блоками — с использованием feature‑флагов.
Какие зависимости оказались блокирующими для перехода?
Наибольшие сложности возникли с Taiga UI и ngx‑formly.
В случае с Taiga UI причиной стала большая разница между версиями 2 и 4. С ngx‑formly пришлось переписать около двух десятков кастомных типов полей, чтобы привести их в соответствие с новой версией библиотеки.
В остальном Angular демонстрирует хорошую обратную совместимость, а автоматические миграции, встроенные в Angular CLI и сторонние schematics, значительно упрощают обновление. Например, ng update @taiga‑ui/cdk закрывает часть проблем автоматически.
Были ли моменты, когда приходилось временно откатываться? Как организовали fallback?
Полноценных откатов не было — изменений оказалось слишком много, и частичные rollback«и не имели смысла.»
Всего получилось три крупных merge‑запроса с более чем тысячей изменений каждый, затрагивающих весь проект. Сначала мы обновили внутренние тестовые среды (PIM и CRM). Это позволило организовать длительный этап внутреннего тестирования: сотрудники активно работали с новой версией интерфейса и оперативно сообщали о проблемах, не затрагивая клиентов.
Как изменилась сборка и CI/CD‑пайплайн?
Существенных изменений не потребовалось. Единственное — в CI пришлось обновить Node.js до версии 22 LTS, чтобы корректно работали настройки module=ES2022 и moduleResolution=bundler в TypeScript.
Какие breaking changes оказались наиболее критичными?
Сам Angular показал себя очень стабильным: даже при обновлении через несколько мажорных версий изменения в коде минимальны.
Основные проблемы, как и ожидалось, были связаны со сторонними библиотеками, поддержка которых либо замедлилась, либо прекратилась вовсе. В таких случаях приходилось искать альтернативы или писать собственные решения.
Какие инструменты и ресурсы оказались наиболее полезны?
Официальный Angular Update Guide — основной ориентир при миграции.
ESLint с правилами @angular‑eslint — помог автоматически исправить множество проблем.
Репозитории и документация библиотек на GitHub — часто приходилось заглядывать в исходный код Nebular и Taiga UI.
DeepSeek — использовался как «лектор» для быстрого поиска ответов на точечные вопросы.
GitHub Copilot в агент‑режиме пробовали применять для миграций и рефакторинга SCSS, но на практике он часто генерировал код, ломающий вёрстку. В итоге ручная работа оказалась быстрее и надёжнее.
Как изменилась производительность, размер бандла и скорость разработки?
Результаты оказались заметными:
холодный старт ng serve сократился примерно с 25 секунд до менее чем 6;
HMR с Vite теперь отрабатывает менее чем за секунду вместо 3–6;
время production‑сборки (ng build ‑configuration=production) уменьшилось примерно на 35%;
размер основного бандла сократился незначительно (около 5%), так как основные «тяжеловесы» — сторонние библиотеки, но tree‑shaking собственного кода стал эффективнее.
Что сработало особенно хорошо и что бы вы посоветовали другим командам?
Инвестировать время в подготовку: привести в порядок зависимости и отказаться от legacy‑peer‑deps.
Заранее продумать стратегию тестирования — внутренний beta‑тест оказался самым эффективным вариантом.
Работать в изолированной ветке и не делать миграцию напрямую в основной.
Максимально использовать автоматические миграции и линтеры.
Не спешить с внедрением новых возможностей Anrular вроде signals — сначала убедиться, что команда к этому готова.
Внимательно читать release notes и changelogs. В них часто содержится критически важная информация.
Какие риски вы недооценили и что бы сделали иначе?
Мы недооценили риск, связанный с кастомными форками библиотек. В следующий раз мы бы либо заранее искали альтернативы, либо планировали замену таких зависимостей до обновления ядра фреймворка. Также стоило сразу внедрить более строгие линтеры для нового синтаксиса.
Были ли проблемы с SSR, hydration и компонентной архитектурой?
С SSR (Angular Universal) сложности действительно были. Новая non‑destructive hydration потребовала адаптации: мы сталкивались с ошибками NG0500 из‑за несовпадения DOM на сервере и клиенте.
Основные причины:
прямые манипуляции с DOM через document или ElementRef в ngOnInit;
использование setTimeout без корректной обработки на сервере;
сторонние библиотеки без поддержки SSR.
Проблемы решались аудитом кода и оборачиванием таких операций в isPlatformBrowser. Переход на Standalone Components, напротив, прошёл очень гладко и стал одним из самых позитивных изменений за всё время миграции.
Каковы перспективы работы на Angular 19 и дальнейшие шаги?
Vite‑сборка, Signals, новый control flow, Standalone API и обновлённый синтаксис шаблонов делают код более декларативным и понятным. Мы планируем аккуратно наращивать опыт работы с signals, полностью отказаться от NgModules и глубже поработать с SSR и гидратацией. После этой миграции мажорные релизы Angular перестали пугать.
Практический чек-лист: обновление проекта до Angular 19
В завершение интервью — краткий практический чек‑лист, сформированный на основе опыта команды Compo Soft. Он не заменяет официальную документацию, но помогает структурировать процесс обновления и избежать типовых ошибок, с которыми сталкиваются команды в крупных проектах.
Шаг 1. Ознакомьтесь с примечаниями к выпуску Angular 19
Изучите release notes и журнал изменений, чтобы понять, какие новые возможности появились, какие API объявлены устаревшими и какие изменения могут нарушить обратную совместимость.
Шаг 2. Создайте резервную копию проекта
Убедитесь, что проект находится под контролем версий и текущее состояние зафиксировано перед началом миграции.
Шаг 3. Обновите глобальную версию Angular CLI
Выполните команду:
npm install ‑g @angular/cli@19
Шаг 4. Обновите Angular в проекте
Запустите обновление основных пакетов:
ng update @angular/cli@19 @angular/core@19
Шаг 5. Обновите версию TypeScript
Установите рекомендованную версию:
npm install typescript@5.6 ‑save‑dev
Шаг 6. Обновите остальные зависимости Angular
Проверьте и обновите связанные пакеты:
ng update @angular/forms @angular/router @angular/material
Шаг 7. Актуализируйте сторонние зависимости
Выполните npm outdated и обновите устаревшие пакеты с помощью npm install package‑name@latest, уделяя особое внимание совместимости с Angular 19.
Шаг 8. Разберите breaking changes и устаревшие API
Последовательно устраните критические изменения, связанные со Standalone Components, новым control flow и системой гидратации.
Шаг 9. Запустите и протестируйте приложение
Проверьте проект с помощью ng serve, ng test и ng e2e, уделяя внимание SSR и клиентской гидратации, если они используются.
Шаг 10. Оптимизируйте конфигурации сборки
Обновите angular.json и tsconfig.json в соответствии с рекомендациями Angular 19.
Шаг 11. Выполните production‑сборку
Запустите:
ng build ‑configuration=production
и проверьте время сборки, размер бандлов и предупреждения.
Шаг 12. Развертывание и мониторинг
Выкатите обновлённую версию в рабочую среду и в первые дни внимательно отслеживайте ошибки и показатели производительности.