Комментарии 13
Очень странный кейс - сидеть 3 года и ничего не делать, а потом все переписывать.
За монорепом нужно следить и ухаживать, поддерживать все в актуальном состоянии. Постоянное обновление Angular и NX, а также pnpm audit
Кто сказал что никто ничего не делал) Не обновляли по стратегическим причинам: сначала приоритет был на стабильности production (риск breaking changes в Angular 14-17 с Ivy, SSR и standalone components мог сломать legacy-функционал) и команда фокусировалась на бизнес-фичах без техдолга (работает - не трогай). Ну и если глянуть на Netflix или GitHub, то они тоже порой не бегут за апдейтами по 2-3 года. Так что местами это нормальная практика.
Нет, это не нормальная практика. И со стабильностью и с безопасностью - она никак не связана. Как я указал выше, нужно во время обновляться и подтягивать все проекты. Если это делать системно - все работает отлично и никаких side effects не возникает, прод работает ожидаемо, хоть с SSR, хоть без.
Как на моей прошлой работе, где монореп был гигантский, с кучей проектов и тысячами разработчиков, так и на текущей работе - где монореп, уже по-меньше - без разницы, версия ангуляра всегда поддерживается в актуальном состоянии. Обычно, спустя 1-2 месяца после релиза, все обновляем. А в промежутках еще и минорные версии подтягиваем...
Обновление спустя 1-2 месяца после релиза - это круто. Вы молодцы, завидую.
Мы больше ориентированы на бизнес-процессы клиентов и их потребности. Технический долг возвращаем когда он в самом деле появляется.
У нас большая кодовая база и обновление спустя пару месяцев после релиза мы точно не сможем делать т.к. внешние зависимости могут быть несовместимы с новой версией по полгода и далее. Форкать чужие библиотеки и потом назад переходить с форка на основную ветку - не всегда оправдано.
"никаких side effects не возникает" - здесь вот не соглашусь. Это риск. Ни раз нарывались на регрессии как в Ng так и в свежих версиях библиотек. Для себя выбрали стратегию не частых обновлений, с вдумчивым и растянутым по времени бета-тестом. Когда сотрудники могут 1-2 месяца работать с next версией продукта и только после этого будет общий релиз.
Так, у всех большая кодовая база. И обновление самого Ангуляра - это не самая сложная задача. Гораздо сложнее - это статический анализ кода и написание патчей под сторонние зависимости.
Не понимаю, что вы доказываете? Критика ради критики.
Вот смотрите, у нас Angular и Taiga UI, супер-крутая библиотека от Тинькова. Angular 16 выходит в мае 2023, а Taiga с поддержкой Angular через 15 месяцев, в августе 2024. Как в этом случае обновиться за 1-2 месяца после релиза?
Менять тайгу на что-то другое, переписывать код приложения и переучиваться всем на ходу? Ставить в legacy peer deps режиме и ловить баги? Если зависимостей мало или они быстро обновляются - можно порадоваться за вас. Если нет - обновляемся через 1-1.5 года после выпуска свежего ангуляра.
Не понимаю, что вы доказываете?
Я ничего не доказываю, я написал в первом комменте - что, это очень странный кейс. Для фронта, где все постоянно и быстро меняется - такая практика выглядит очень архаично.
Но теперь понятно, раз вы юзаете Bootstrap и внешние UI-либы - соответственно, делаю вывод что у вас мало компетенций по данной теме. Зачем тянуть к себе в проект такие простые штуки... Видимо, вы еще не выросли.
Ну, ок.
Да, мы не спешим очень быстро меняться и следовать за модой которая во фронте часто меняется. В этом плане да, не выросли. Неспешно используем Angular ещё с первой, js версии и постепенно дошли до 19-ой. Bootstrap 5-ой версии тоже закрывает часть наших задач. Он хорошо документирован, прост и продуман, в него легко погружать программистов. Менять его тоже пока не собираемся. Не спешим никуда, медленно и поступательно развиваемся.
Теперь все встало на свои места :)
Сразу чувствуется влияние бэкендов. Это у них один раз настроил и все, ближайшие годы, пока не прилетит - ничего не трогаем :)
На фронте - другой подход. Для примера запустите в своем монорепе аудит (npm/pnpm audit или какой у вас пакетный менеджер используется), в идеале должно быть 0 критических уязвимостей.
Спасибо за интересную статью! Подскажите, насколько я понял вы ещё не перешли на Vite? Мы попробовали, но новый сборщик стал дробить весь код на очень маленькие чанки, а приложение не малое и по итогу скорость загрузки уменьшилась (особенно на низкой скорости), так как у браузера не бесконечное количество потоков. Вы с таким пока не столкнулись?
Здравствуйте. Мы на Vite и маленькие чанки это прекрасно.
Плюсы stand alone и небольших чанков
Возможность использовать lazy load компонентов прям в роутинге https://angular.dev/reference/migrations/route-lazy-loading
Tree shaking сильно эффективнее работает с мелкими чанками
Один большой модуль даст вам более быструю полную загрузку приложения, но доступным для действия пользователя приложение станет заметно позже. Т.е. в браузере долгое время будет отображаться процесс загрузки, вместо (пусть даже частично) доступного интерфейса. Stand alone даёт более быстрый интерактив в браузере
Так же маленькие чанки дают возможность локально использовать Hot Module Replacement (HMR) для стилей и шаблонов. Это значительно ускоряет обновление в браузере при активной работе со стилями или html
Что делать если есть проблемы с исчерпанием лимита соединений
Смотрите детально почему вы загружаете много всего при старте. Это в самом деле необходимо?
Можно использовать супер-крутую штуку @defer - https://angular.dev/guide/templates/defer для lazy load части компонентов. Вы можете совсем не грузить код с которым пользователь не работает и делается это элементарно, без сложное конфигурации. У @defer есть разные стратегии загрузки кода - idle, viewport, interaction, hover, ... Возможно сможете перенести часть функционала на отложенную загрузку и облегчите приложение в целом.
В итоге мое мнение - чем меньше будут чанки тем лучше. Даже если их будет много.
Спасибо за подробный ответ) Насколько у вас большое приложение и используете ли вы preloading чанков?
Мы как раз сейчас движемся в сторону оптимизации загрузки, пока вернулись на webpack. Оптимизировали размеры основных чанков, standalone с lazy routing уже настроен, добавили defer, настроили Service Worker и перестали грузить то, в чём не было необходимости. В ближайшее время, думаю, снова попробуем Vite, должно стать получше, но уверен нужны будут ещё оптимизации, спасибо за совет!
У нас два приложения на 4+ и 5+ мегабайт в прод сборке. Чанки анализируем через http://esbuild.github.io/analyze/ после сборки ng build --stats-json
Хороший анализатор. Рекомендую.
Прелоад не используем. Наоборот, грузим только то, что нужно сейчас пользователю. Приложение у нас с настроенным service worker'ом, он фоном смотрит на сервер и если был свежий релиз - сам тихонько загрузит все чанки и предложит обновиться в UI. Это удобно. Пользователь не отвлекается на загрузку и видит кнопку обновления только если все чанки были уже загружены браузером.
Да, холодный старт будет медленнее, но не могу придумать сценариев в нашем окружении где webpack был бы быстрее и оптимальнее Vite. Гибче, может быть, но не быстрее. Не зря на него официально перевели Angular. Надо смотреть ваше приложение, гонять его в Performance анализаторе консоли Google Chrome с разными настройками и искать узкое место. Сервер http2? Он корректно настроен? Надо смотреть зачем вам сразу при старте грузить много кода если можно показать UI, дать с ним работать и догружать куски интерфейса на ходу. Общих рекомендаций к сожалению не дам, надо в детали погружаться.
Как мы пережили несколько мажорных обновлений Angular в B2B-платформе