Angular NX — импорт общих библиотек по версии

Я относительно новый разработчик Angular, который хочет создать набор приложений Angular, которые совместно используют библиотеку пользовательских компонентов (и, вероятно, некоторые другие утилиты/интерфейсы).

Nx от Nrwl выглядит как отличная система для организации этих частей, поэтому я думаю, что буду использовать ее.

Однако у меня есть одна идеальная спецификация, которую, судя по моим поискам, Nx на самом деле не поддерживает: возможность версионировать библиотеки так, чтобы одно приложение могло использовать версию 1.0, а другое — версию 2.0 того же компонента. библиотека, например.

Таким образом, я мог бы изменить, скажем, компонент Dropdown для приложения 2, не затрагивая приложение 1 вообще, потому что приложение 2 просто указывало бы на новую библиотеку, а приложение 1 — на старую.

Кто-нибудь знает хороший способ сделать это в Nx (или хорошие ресурсы, чтобы понять это, или хорошие условия поиска, чтобы найти эти ресурсы)? Возникли проблемы с поиском руководства здесь или выяснением того, возможно ли это вообще, как я думал об этом.

Очевидно, есть несколько более хакерских способов сделать это:

  • Имеют дублирующиеся "версионные" компоненты (Dropdown1, Dropdown2).
  • Сделайте то же самое для библиотек компонентов (import @cl2/Dropdown)

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


person Sasha    schedule 26.03.2020    source источник


Ответы (1)


Весь смысл NX и монорепозитория в том, что все должно работать под управлением «главной» версии.

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

Если вы не хотите делать это таким образом, вы можете просто иметь библиотеку компонентов в виде отдельного репозитория и опубликовать их в npm, а затем использовать их в различных приложениях с помощью npm.

person Leon Radley    schedule 26.03.2020
comment
все должно работать на главной версии -> тесно связанные жизненные циклы компонентов -> монолит. Это может быть подход NX, но он по своей сути не требуется для подхода монорепозитория. монорепозиторий != монолит. У меня был тот же вопрос о NX. Нет ли способа иметь независимые жизненные циклы? - person Tom; 27.03.2020