Навести порядок в структуре проекта

[in19farkt]

Нужно:

• навести порядок в файлах инициализации приложения
• максимально отделить базу/ядро проекта, от накручиваемого поверх функционала (фичи, сервисы, модули, типы и хелперы конкретной бизнес модели).
• определить откуда и в каком формате ядро забирает функционал, чтобы инициализировать/запустить приложение
• определить что можно брать из ядра (базовые элементы UI, типы, хелперы, и т.п.)

Это позволит нам написать небольшой скрипт очищающий проект от всякого шлака, чтобы можно было быстро стартовать проекты и не поддерживать 2 ветки (опыт с mvp-base показал что это гиблая затея).

@Znack @NikitaRzm хотел бы услышать ваше мнение/предложения.

[Znack]

Хорошая тема, но я скорее всего уже на выходных смогу тут предметней обсуждать. В целом я прямо за, но нужны детали, что считать ядром, а что нет, как это выносить и куда :)

По-хорошему, в ядре оставить только архитектурные вещи и бутсрапинг этой архитектуры. В идеале фичи и модули где-нибудь в конфиге объявлять списком и просто их ядро будет из конфига цеплять и запускать.

[in19farkt]

Ага, тут нужно хорошенько всё обдумать и спроектировать. Я вот про конфиг чето даже не подумал, хорошая идея))

[in19farkt]

И есть еще идея запилить cli для быстрого подтягивания всяких шаблонов. Туда убрать фича-генератор, добавлять туда шаблоны для сервисов различных (api, notifications, ...), базовый UI можно туда же спрятать, набор файнал-форм филдов, возможно что-то еще.

Тогда с нормально оформленным ядром, можно будет выпиливать вообще всё кроме ядра, и на конкретном проекте с помощью cli забирать всё что нужно для этого проекта.

[NikitaRzm]

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

Нельзя давать лазить туда никому лазить по идее, надо об этом подумать и расписать )

[in19farkt]

И еще в контексте этой же задачи можно решить проблему раздутого package.json из-за скриптов на все случаи жизни.

[NikitaRzm]

ну мне нравится npm тем что там баш, и если это в скрипты унести - больше свободы - начнется анархия ) Тут надо еще сильнее думать, npm хороший раннер, очень хороший)

[in19farkt]

Ранер-то хороший, но ты зайди в package.json, там определенно нужно рефакторить скрипты)) Многие вещи возможно и не должны находиться в энвах, и могут уйти например в конфиг проекта, плюс много дублирования энвов.

[NikitaRzm]

Энвы решаются через dotenv :)

[in19farkt]

ага, или туда)

[in19farkt]

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