Было бы интересно взглянуть на сравнение с инструментом Framer так как он на выходе выдает готовые компоненты на реакте (и так же можно писать свои). Если я правильно понял из статьи то это более близкий конкурент чем фигма где вроде только статика (не пользуюсь фигмой)
Lerna вроде сейчас находится в статусе только поддержки, поправьте если неправ. Тоже использовал лерну пока не появился yarn workspaces, по-моему как раз тогда разработчики лерны и перестали как то особо развивать проект.
Рассматривается ли вами переход на Preact? Это даст более маленький бандл и возможные ускорения в работе с DOM. Конечно некоторые фичи там отсутсвтуют, но их убрали потому что ими вроде и так никто не пользуется.
Сам я не разработчик реакт, мне скорее интересно мнение по этой теме если таковое имеется.
Да, в этом случае появляется необходимость использования разных портов
В нашей фирме мы делаем огромное количество проектов и запоминать для каждого порт было бы ужасно, еще одиним решением было держать запущенным только один проект. И оба эти решения имеют свои минусы.
На помощь нам пришел Traefik, мы назначили каждому контейнеру домен вида project.domain.localhost и теперь когда нам надо работать над отдельным проектом достаточно написать его домен в браузере + .localhost что бы обратиться к бегущему локально контейнеру этого проекта.
Прошу прощения за сумбурный коментарий, писал его еще до первой кружки кофе.
У меня стояла подобная задача и мне показалось ваше решение слегка усложненным и недостаточно автоматическим. Поэтому хочу написать отличия от вашего решения и спросить что вы о них думаете.
1.
Например, мы можем явно сконфигурировать сеть — 192.168.220.0/28.
Можно избежать конфигурации подсети, если вы собираетесь использовать makefile. Тогда достаточно на команду поднятия контейнеров передать что-то подобное: XDEBUG_REMOTE_HOST := $(shell hostname -I | grep -o "^\S*") и заменить в компоузе на remote_host=${XDEBUG_REMOTE_HOST}
Минусы: Не будет работать на windows.
2.
2. Прописываем узлы first.loc и two.loc в файле /etc/hosts
Если использовать трафик и домены типа your.domain.localhost, то можно избежать пункта с изменением файла хостс.
Плюсы: При добавлении/удалении сервисов не надо будет заставлять всех менять файл хостс т.к. вся конфигурация трафика будет прямо в репозитории.
Я использую указанный мной подход когда есть четко заданные аргументы которые можно использовать. Они отлавливаются через case и записываются в соответственную переменную. Удобно когда есть переменные с задаными значениями по умолчанию.
Пример из реального скрипта:
RESTORE=0
ENCRYPT=1
ARGPAD=1 # Если в коде где-то требуются оставшиеся аргументы (например список файлов) их можно получить прибавив этот 'отступ'
for argument in ${@}; do
case $argument in
-r | --restore )
RESTORE=1
ARGPAD=$(($ARGPAD + 1))
;;
-e=* | --encrypt=* )
encrypt=${argument##*=}
if [ "$encrypt" == "non-encrypt" -o $encrypt == 0 ]; then
ENCRYPT=0
fi
ARGPAD=$(($ARGPAD + 1))
;;
-* )
ARGPAD=$(($ARGPAD + 1))
;;
esac
done
Lerna вроде сейчас находится в статусе только поддержки, поправьте если неправ. Тоже использовал лерну пока не появился yarn workspaces, по-моему как раз тогда разработчики лерны и перестали как то особо развивать проект.
Рассматривается ли вами переход на Preact? Это даст более маленький бандл и возможные ускорения в работе с DOM. Конечно некоторые фичи там отсутсвтуют, но их убрали потому что ими вроде и так никто не пользуется.
Сам я не разработчик реакт, мне скорее интересно мнение по этой теме если таковое имеется.
В нашей фирме мы делаем огромное количество проектов и запоминать для каждого порт было бы ужасно, еще одиним решением было держать запущенным только один проект. И оба эти решения имеют свои минусы.
На помощь нам пришел Traefik, мы назначили каждому контейнеру домен вида project.domain.localhost и теперь когда нам надо работать над отдельным проектом достаточно написать его домен в браузере + .localhost что бы обратиться к бегущему локально контейнеру этого проекта.
У меня стояла подобная задача и мне показалось ваше решение слегка усложненным и недостаточно автоматическим. Поэтому хочу написать отличия от вашего решения и спросить что вы о них думаете.
1.
Можно избежать конфигурации подсети, если вы собираетесь использовать makefile. Тогда достаточно на команду поднятия контейнеров передать что-то подобное: XDEBUG_REMOTE_HOST := $(shell hostname -I | grep -o "^\S*") и заменить в компоузе на remote_host=${XDEBUG_REMOTE_HOST}
Минусы: Не будет работать на windows.
2.
Если использовать трафик и домены типа your.domain.localhost, то можно избежать пункта с изменением файла хостс.
Плюсы: При добавлении/удалении сервисов не надо будет заставлять всех менять файл хостс т.к. вся конфигурация трафика будет прямо в репозитории.
Реализация с адресацией выглядит слегка костыльной, рассматривали ли вы traefik если да то почему он вам не подошёл?
Я использую указанный мной подход когда есть четко заданные аргументы которые можно использовать. Они отлавливаются через case и записываются в соответственную переменную. Удобно когда есть переменные с задаными значениями по умолчанию.
Пример из реального скрипта: