Шаблон Monorepo для двух разных угловых приложений?

До сих пор у нас было одно приложение angular 8. Но теперь нам нужно создать новое приложение администратора, пользовательский интерфейс которого будет аналогичен существующему приложению (аналогичный пользовательский интерфейс, как в аналогичном компоненте входа, боковой панели, панели навигации и т. Д.). Поскольку эти два приложения будут развернуты на двух разных серверах, но будут совместно использовать компоненты друг с другом, мы решили хранить два разных исходных кода в одном репозитории с общей библиотекой компонентов.

Наше существующее приложение создано с использованием Jhipster.

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

Я прочитал статью на странице Создание библиотек для Angular. Однако я не смог найти материала о том, как изменить существующий процесс сборки для создания двух разных приложений? Во всех статьях, которые я читал, были команды Angular CLI для создания различных приложений. Поскольку у нас уже есть веб-пакет в качестве сборщика, как мне настроить его для сборки обоих моих приложений? По сути, все мои сомнения касались того, как расширить существующие инструменты, которые мы используем для создания, тестирования и поддержки этих двух разных приложений.

Затем я прочитал о шаблоне монорепо и наткнулся на Nx от nrwl.io. Насколько я понял, это оболочка поверх angular CLI для поддержки шаблона монорепозитория и поставляется со всеми инструментами, которые мне понадобятся для поддержки обоих приложений.

Итак, мой вопрос: стоит ли использовать шаблон монорепозитория, когда вам нужно только разделять код между двумя приложениями? Это связано с простотой разработки и временем, которое потребуется для преобразования существующего приложения для поддержки шаблона монорепозитория (настройка инструментов, как в Nx), который я прочитал, вызывает у меня головную боль.


typescript angular nrwl-nx jhipster
person kiranghule27    schedule 03.01.2020    source источник
comment
Обратите внимание, что процесс сборки веб-пакетов, созданный JHipster, не полностью совместим с angular-cli, поэтому я сомневаюсь, что Nx будет работать. Общая библиотека мне нравится, у вас будет 3 папки: lib, app1 и app2. Ваш процесс lib builmd должен быть развернут в вашем локальном реестре npm (например, Sonatype Nexus), и 2 приложения должны ссылаться на него в своих соответствующих package.json   -  person Gaël Marziou    schedule 03.01.2020
comment
Согласились, что процесс сборки JHipster webpack не полностью совместим с angular-cli. Однако с подходом публикации библиотеки к локальному реестру npm у меня были бы накладные расходы на управление версиями для библиотеки и обновление в обоих приложениях. Эти накладные расходы, похоже, устраняются шаблоном монорепозитория, как показано в руководстве Nx.   -  person kiranghule27    schedule 04.01.2020

Ответы (1)


arrow_upward
0
arrow_downward

Отказ от ответственности, я большой поклонник NX.

Как вы можете изменить существующий процесс сборки для создания двух разных приложений?

Не уверен, что смогу проверить это следующее утверждение, но в прошлом, я считаю, что документы Angular были сформулированы для отдельных приложений. Совсем недавно (v7 или 8) словарь документации был обновлен вокруг Рабочие места. Возможно, из-за растущей популярности NX (они были первопроходцами в разработке монорепозиториев на Angular еще до Angular 6)?

Стандартный интерфейс командной строки Angular

Поскольку вы используете Angular 8, вы можете создавать приложения точно так же, как если бы вы генерировали компонент с помощью Angular CLI: ng generate application admin-app. Кроме того, ng build принимает имя приложения в качестве параметра, так что это все, что вам нужно для создания двух отдельных приложений с помощью Angular CLI из коробки. ng build public-app и ng build admin-app

Однако кодовая база может стать очень дезорганизованной, если вы сделаете это в уже существующем приложении (также известном как приложение, созданное с помощью ng new), потому что новое приложение будет помещено в каталог projects внутри кодовой базы. Вы бы в итоге получили App-Ception, что я считаю ужасной идеей.

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

Стоит ли использовать шаблон монорепозитория, когда вам нужно использовать общий код только между двумя приложениями?

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

NX

NX предлагает многое. Сказать, что это оболочка для Angular CLI, на самом деле только поверхностно. У него есть набор схем, которые расширяют / улучшают существующие схемы Angular CLI (ng generate app|component|lib и т. Д. - это схема). Это также упрощает включение улучшенных инструментов из коробки (Jest> Karma; Cypress> Protractor). У него также есть собственный инструмент командной строки, который решает множество проблем, связанных с структурой монорепозитория (посмотрите их гиды)

Попробуйте включить его в существующую базу кода

На основе их Документы по началу работы, вы можете легко попробовать, просто выполнив:

ng add @nrwl/workspace

person Chris Newman    schedule 03.01.2020
comment
Спасибо за вклад. Я выбрал Nx в основном потому, что считаю, что мне придется внести много изменений в конфигурацию webpack, чтобы поддерживать сборку нескольких приложений. Только один вопрос, у Nx есть tslint в качестве линтера по умолчанию, и я хотел бы изменить его на eslint, который я уже настроил, где в файле angular.json мне нужно будет внести изменения для его интеграции? - person kiranghule27; 05.01.2020
comment
Извините за медленный ответ. Я немного изучил это, согласно комментариям по этой проблеме на NX Github, это то, что будет реализовано командой Angular CLI (а не командой NX): github.com/nrwl/nx/issues/1912 - person Chris Newman; 10.01.2020