Комментарии 12
Если б ангуляр еще не был бы монолитом, пытающимся объять необъятное — цены бы ему не было. А так очень забавно наблюдать, как прекраснейшие идеи из ангуляра (а их там довольно много, без шуток, начиная с модульности и заканчивая (старым) роутингом, который потом превратили в УГ, но переизобрели обратно) потом заново реализовываются в разных мелких либах и фреймворках, практически таким же образом — и получают большую популярность, потому что идеи-то прекрасные, особенно когда не надо для их использования вкорячивать ангуляр целиком.
Не могу полностью согласиться, мне как раз нравится что все что нужно идет из коробки, по желанию можно добавить NgRx. Надеюсь что они доведут treeshaking до ума, и тогда большой размер исходного ангуляра станет меньшей проблемой. А так работа с ним пока не доставляла каких-то огорчений.
НЛО прилетело и опубликовало эту надпись здесь
И как происходит аудит и менеджмент сторонних зависимостей, например, в ваших проектах, как я полагаю, составленных из множества библиотек?
Да так же, как везде. Фиксируем версии, проверяем все непрямые зависимости, по необходимости вообще выгружаем зависимости себе и запиливаем регламент их обновления, включающий и повторный аудит.
Например, с Ангуляром я могу заложиться на срок жизни (поддержки) всего монолита
Если вы в ангуляре собственноручно и под крылом одной конторы нафигачили от начала и до конца проект — то да. Если вы взяли ангуляр и поняли, например, что красивые контролы вам ангуляр сам не нарисует, и пошли собирать сборную солянку из готовых ангуляр-компонентов — поздравляю, у вас всё точно так же, как и у других без ангуляра. И солянка ваша может развалиться примерно с такой же вероятностью.
НЛО прилетело и опубликовало эту надпись здесь
Про контроль зависимостей понял, так и думал, вы используете какие-то автоматические инструменты для этого?
Ни разу не приходилось работать с настолько большой солянкой, чтоб это стало надо. Один раз, когда нужен был жесткий контроль лицензий — написали (за полчасика) шелл-скрипт, читающий license из package.json на предмет всяческого ата-та (а потом заменили его на чуть более умный сканер лицензий на ноде, который вообще все файлы смотрел на предмет ключевых слов не в белом списке).
Ну и там естественно регламент был, чтоб при каждом обновлении зависимостей это всё прогонялось, и любые положительные срабатывания либо отправлялись на разборки с юристами, либо же рубились бы обновления.
Что касается моих проектов, то нам повезло мы почти все пишем сами, что касается UI.
Ну да, и это тот самый случай где ангуляр действительно очень уместен.
Насколько я понимаю, как минимум material стал частью ангуляра, про сторонние компоненты понятно, что ситуация таже
Проблема высосана из пальца. В процессе развития любое приложение обрастает библиотеками и самый легкий Вью или Реакт начинают напоминать Франкенштейна. Так что лучше сразу обо всем позаботиться)
Ну вот в том-то и дело, что не любое.
И кроме того, есть еще другой момент — вот эти самые «библиотеки», которые не только с npm берутся, а иногда и собственные пишутся. Когда у вас есть небольшая библиотека (скажем, компонентов UI, хотя есть и другие варианты), но она с собой тянет всю массу ангуляра — это грустно. Когда у вас таких небольших библиотек три, и каждая тянет с собой отдельную версию ангуляра (потому что версии разные) — это уже не грустно, а ужасающе.
И кроме того, есть еще другой момент — вот эти самые «библиотеки», которые не только с npm берутся, а иногда и собственные пишутся. Когда у вас есть небольшая библиотека (скажем, компонентов UI, хотя есть и другие варианты), но она с собой тянет всю массу ангуляра — это грустно. Когда у вас таких небольших библиотек три, и каждая тянет с собой отдельную версию ангуляра (потому что версии разные) — это уже не грустно, а ужасающе.
Заметил небольшую очепятку в статье в самом начале раздела «как обновиться до 9 версии»: «Пройлите»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Angular 9 теперь доступен — Ivy прибыл