Ситуация
Я создаю набор приложений на основе Гнезда JS monorepo .
У меня есть несколько apps
, которые опираются на несколько общих libs
.
Эти apps
похожи друг на друга, но могут отличаться по некоторым функциям, поэтому монорепо имеет смысл.
Некоторые из libs
предоставляют @Controller()
, который @Render()
просматривает общие функции.
Допущения
Файлы шаблонов должны находиться в модуле. Поскольку существует высокая связь между контроллером и отображаемым шаблоном,
Я считаю, что имеет смысл хранить файлы шаблонов представлений (.hbs, .e js, что угодно) в модуле libs
, обеспечивая @Controller
,
В дистрибутив / при создании приложения должны быть отправлены только соответствующие шаблоны
У меня есть некоторые деловые / юридические / ограничения безопасности, которые вынуждают меня избегать присутствия некоторых libs
в некоторых apps
производственных условиях. например. my-secret-algo-lib
не должно присутствовать в my-public-unsecure-internet-app
Таким образом, создается такая структура файла:
monorepo/
apps/
my-first-app/
src/
main.ts <-- nest bootstrap function is here
...
my-second-app/
...
libs/
my-first-lib/
src/
my-first-lib.module.ts
my-first-lib.controller.ts <-- @Render('my-view')
...
views/
my-view.ejs <-- the view
...
Цель
Я хочу чтобы получить сборку, которая выдает следующую файловую структуру:
dist/
apps/
my-first-app/
main.js
views/
my-first-lib/
my-view.ejs
Предполагая, что:
my-first-app
import my-first-lib
- Представления, которые могут существовать в неиспользованные библиотеки не должны включаться в
dist/
Вопросы
- Возможно ли это с существующими инструментами?
- Будет ли это рассматриваться как анти-паттерн ? если да, то как мне структурировать вещи?
- Если ответ на оба вопроса "нет", должен ли я что-то построить самостоятельно или присоединиться к каким-либо существующим усилиям?
Другая часть проблемы заключается в том, Nest JS Конфигурация модуля приложения, но, думаю, это будет последним ...