[ARCHIVED] А что там с монорепами / модулями-пакетами?

[azinit]

Хочется услышать как дела:

• в проектах моно-репах
• в проектах, где некоторые модули/подмодули объявлены внутри как пакеты и опубликовываются
• в проектах где функционал доставляется в виде пакетов
• и т.д.

Можете писать о всем:

• и проблемы feature-sliced в таких проектах
• и ваши структуры/решения, которые помогают в разрешении этих проблема
• о вашем понимании, какие должны быть сущности в таких пакетах
• должен ли применяться в принципе feature-sliced вне проектов

  (например в оч-оч сложных пакетах-компонентах или пакетах, с интеграцией определенной логики)

[binjospookie]

У меня репозиторий под lerna, функционал поставляется в продукт npm-пакетами.

Самая большая проблема, с которой можно столкнуться -- package hell. Он не о количестве пакетов, а об их связности.

Пример

Мы обновляем пакет X, от которого зависят Y, Z. От Y зависит A. от Z -- W. Вот тут-то и начинается самое "веселье"

Все возможные связи запомнить трудно и бесполезно (лишняя ментальная нагрузка). А вот ошибиться легко.

Если такая ситуация всё же случилась, то, скорее всего, из за плохой структуры проекта.

[binjospookie]

В данном походе внутри feature появляется директория integration. В ней содержится код, позволяющий интегрировать фичу. В идеале, экспортится 1 функция: makeFeature. Которая может принимать в себя:

• transport
• переводы
• итд

[binjospookie]

Важно уметь переключать позицию наблюдателя между: "разработчик чёрного ящика" и "интегратор чёрного ящика".

[binjospookie]

Ещё может появляться специфика в получении данных (на интеграционном слое):

1. фича работает на отдельной странице => все необходимые данные с бэка получает сама
2. фича работает в общем "поле" и данные берёт из каких-то общих хранилок

Зачем:
Двум фичам, работающим на одной странице, необходимо получить данные о пользователе. Если будет выбрана стратегия "мне нужны данные, я иду за ними", то она приведёт к дублированию запросов.

[carina-akaia]

api, entities, features, lib, ui у меня являются пакетами с префиксом и лежат в подкаталоге packages. Менеджмент осуществляется через yarn workspaces.

Кстати, а в shared могут лежать entities и features? Мы кажется с этим не определились.
Мой кейс -- монорепо с двумя приложениями, которые от всех этих пакетов зависят оба, а позже у каждого приложения внутри будет собственная feature-sliced структура.
То есть, для каждого из приложений shared'ами являются не только api, lib, ui, но и features, entities

В связи с чем у меня появилась идея:
Что, если переименовать shared в packages, и, возможно принять их оформление как пакеты за стандарт?

@sergeysova как быть с общими features и entities в монорепо с несколькими приложениями, если их нельзя класть в shared?

[azinit]

Кстати, а в shared могут лежать entities и features?

Ответил тут

TL;DR: - нет, по бывают интересные парадоксы

[7iomka]

Можно посмотреть пример вашего проекта? У меня похожая задача, интересно к какой структуре вы в конечном счёте пришли.

[sergeysova]

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

[azinit]

Здесь кста тож про модули-пакеты речь заводится (тож как про Advanced Level)

https://alexmngn.medium.com/why-react-developers-should-modularize-their-applications-d26d381854c1