@Persotr27

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

Всем привет.

У меня имеется проект, который включает в себя приложение для админов, и приложение для пользователей. По сути, в них используются общие модели, но для каждого приложения я опредеяю собственные типы (дублирующиеся). Кажому приложению соответствует отдельная папка в репозитории проекта.

Как можно избежать дублирования типов (определения интерфейсов) между приложениями? Я конечно подумываю о написании npm пакета и последующих его установках в оба проекта, но стоит ли оно того? Или в принципе дублировать типы между приложениями практика нормальная?
  • Вопрос задан
  • 61 просмотр
Решения вопроса 1
bingo347
@bingo347
Ищу Java и TypeScript разработчиков
Если Вы предполагаете, что нечто является единой сущностью, то должен быть ровно 1 источник истины, определяющий эту сущность. Типы - это источник истины о структуре Ваших сущностей. Если в двух приложениях Вы оперируете одними и теми же сущностями, то и типы для них должны быть едины, иначе это будет нарушением DRY. Но если по факту сущности разные, то даже если они выглядят одинаково, их нельзя объединить, иначе это будет нарушением SRP.

Что можно сделать если типы описывают единые сущности:
1. Если оба приложения живут в одном репозитории, то можно просто переиспользовать одни и те же модули в обоих приложениях. Можно даже сложить их в общую папку и прописать на нее алиас в tsconfig.json и в конфиге сборки.
2. Если приложение живут в разных репозиториях, то общий код можно вынести в третий репозиторий и подключить его через git модули
3. А если общий код еще и меняется редко, то разбить его на отдельные npm пакеты - хорошая идея. При этом не обязательно заливать его в публичный репозиторий или покупать у npm приватный, и даже свое зеркало ставить не обязательно (хотя и удобно). Можно просто запаковать пакет в .tgz командой npm pack, а потом устанавливать его из этого .tgz через npm i прямо с файловой системы или с любого http сервера. Кроме того npm i можно делать прямо из git репозитория в корне которого лежит package.json, но как по мне - это не очень хорошая затея, так как в git лежат исходники, а в npm пакете должен быть готовый к использованию (собранный) js код.
4. Ну и наконец, единый репозиторий так же можно организовать в несколько пакетов, используя npm workspaces и lerna.

UPD:
Надо ознакамливаться на что ссылаешься...
В русской википедии в статье про SRP понаписано много бреда, которого нет в английской версии.
Забавно, что подобно английской статье, в русской так же ссылаются на Роберта Мартина, который определяет данный принцип правильно (по крайней мере в тех его книгах, что я читал).
Это очень распространенное заблуждение (OMG, я кажется нашел, откуда все эти люди, что приходят на собеседования, понабрались этого бреда...)
Принцип единственной ответственности не про то, что код делает что-то одно или отвечает за что-то одно (какая вообще может быть ответственность у текста?).
Принцип единственной ответственности про то, что у каждой программной сущности есть ровно одно ответственное лицо, и только это лицо является источником изменений в коде этой сущности.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы