fullstack-development
Навести порядок в структуре проекта
Нужно:
- навести порядок в файлах инициализации приложения
- максимально отделить базу/ядро проекта, от накручиваемого поверх функционала (фичи, сервисы, модули, типы и хелперы конкретной бизнес модели).
- определить откуда и в каком формате ядро забирает функционал, чтобы инициализировать/запустить приложение
- определить что можно брать из ядра (базовые элементы UI, типы, хелперы, и т.п.)
Это позволит нам написать небольшой скрипт очищающий проект от всякого шлака, чтобы можно было быстро стартовать проекты и не поддерживать 2 ветки (опыт с mvp-base показал что это гиблая затея).
@Znack @NikitaRzm хотел бы услышать ваше мнение/предложения.
Хорошая тема, но я скорее всего уже на выходных смогу тут предметней обсуждать. В целом я прямо за, но нужны детали, что считать ядром, а что нет, как это выносить и куда :)
По-хорошему, в ядре оставить только архитектурные вещи и бутсрапинг этой архитектуры. В идеале фичи и модули где-нибудь в конфиге объявлять списком и просто их ядро будет из конфига цеплять и запускать.
Ага, тут нужно хорошенько всё обдумать и спроектировать. Я вот про конфиг чето даже не подумал, хорошая идея))
И есть еще идея запилить cli для быстрого подтягивания всяких шаблонов. Туда убрать фича-генератор, добавлять туда шаблоны для сервисов различных (api, notifications, ...), базовый UI можно туда же спрятать, набор файнал-форм филдов, возможно что-то еще.
Тогда с нормально оформленным ядром, можно будет выпиливать вообще всё кроме ядра, и на конкретном проекте с помощью cli забирать всё что нужно для этого проекта.
Да, насчет ядра Серега верно говорит, там должен быть минимум для старта приложения и его конфигурации в плане конфигурации как механизма проекта )
Нельзя давать лазить туда никому лазить по идее, надо об этом подумать и расписать )
И еще в контексте этой же задачи можно решить проблему раздутого package.json из-за скриптов на все случаи жизни.
ну мне нравится npm тем что там баш, и если это в скрипты унести - больше свободы - начнется анархия ) Тут надо еще сильнее думать, npm хороший раннер, очень хороший)
Ранер-то хороший, но ты зайди в package.json, там определенно нужно рефакторить скрипты)) Многие вещи возможно и не должны находиться в энвах, и могут уйти например в конфиг проекта, плюс много дублирования энвов.
На данный момент все наши энвы это по сути публичные глобальные переменные, которые мы хардкодим для того или иного скрипта. А задача энвов как я понимаю прежде всего немного в другом, в том чтобы на стороне сервера, который будет работать с нашим проектом, была возможность через энвы прокинуть какие-то приватные данные в нашу сборку или переопределить какое-то дефолтное поведение.