структура пакета lerna monorepo

Question

Я создаю monorepo для набора приложений React и общего кода библиотеки.Одним из пакетов будет библиотека компонентов.

packages
  app1
  app2
  common-ui
    alert
    button

Я довольно новичок во всей экосистеме React / узлов.

Я просмотрел множество реальных примеров библиотек пользовательского интерфейса - act-bootstrap , material-design-components-реаги * и т. Д.

Кажется, я бы хотел, чтобы каждый компонент в библиотеке Common-UI распространялся в виде отдельных файлов, чтобы их можно было выбирать при импорте в потребляющее приложение.

act-bootsrap делает это, используя babel для сборки "lib".Они встроены в дистрибутив браузера, библиотеку commonjs и библиотеку ES.

material-design-components-реагирует на это, имея свою библиотеку компонентов самим lerna monorepo, причем каждый компонент имеет свой собственный пакет.json, и я полагаю, что они используют webpack для создания каждого компонента по отдельности.

Итак, мой первый вопрос:

1. Является ли структура, подобная материалу, дизайну, компонентам, реагирующим в моей общейПапка пользовательского интерфейса - что-то вроде монорепо в монорепо возможно?

Или мне придется реструктурировать:

packages
  app1
  app2
  alert
  button

Мой второй вопрос:

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

Answer 1

Является ли структура, как материал-дизайн-компоненты-реагировать в моем обычном пользовательском интерфейсе папка - возможно ли создание монорепо в монорепо?

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

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

Первая структура с 3 пакетами является наиболее распространенным способом для запуска вашего репозитория / проекта.

В вашем случае я бы не советовал разделять вашу ux-библиотеку на отдельные файлы. Ваши приложения, вероятно, будут использовать большую часть вашей UX-библиотеки, и, вероятно, у вас не будет столько компонентов, сколько у материала или начальной загрузки. Более того, если вы когда-нибудь достигнете этой точки в своей библиотеке, вы можете отделить их позже. Для справки вы также можете проверить, как lodash публикует каждую из своих функций. Это не отличается от вашего случая (если вы не будете публиковать шрифты / изображения и т. Д.).