А
поменять настройки самой базы, хост, порт и т.п.
Size: a a a
2021 July 22
А
я просто не понимаю почему у приложения должно быть именно два варианта настроек и всё.
МЗ
То еать при активной разработке менять по 20 раз за час?
АБ
Переменные окружения в npm скрипте?
А
смотря какие требования, а зачем менять 20 раз в час?
ДП
Все верно, нужно делать динамику, в моем проекте я сделал чтение важных параметров из консоли, а дальше все конфиги при импорте отдают нужные данные, основной код получает уже готовое и знать не знает про дев прод
А
можно конечно и менять, если нужно :)
МЗ
Вопрос был зачем создавать отдельную переменную, в которой определяется в каком окружении запущена
Я ответил что банально чтобы при запуске можно было автоматически подгрузить тот или иной конфиг и не париться
Понятно что на проде все будет браться из переменных окружения а не из закоммиченного файла конфига
Но для разработки и тестирования удобнее так
Я ответил что банально чтобы при запуске можно было автоматически подгрузить тот или иной конфиг и не париться
Понятно что на проде все будет браться из переменных окружения а не из закоммиченного файла конфига
Но для разработки и тестирования удобнее так
А
так переменная не просто так добавляется, потом где то внутри кода появляется условная конструкция
if (env == 'prod') ... if (env == 'dev') и дальше меняются какие то настройки. Видел такое много раз. Возможно у вас другой случайМЗ
В одном месте
В сервисе конфигурации чтобы подгрузить те или иные настройки
В сервисе конфигурации чтобы подгрузить те или иные настройки
МЗ
То есть банально создаете 3 обьекта с одинаковыми полями и разными настройками
И сервис возвращает один из этих обьектов в зависимости от переменных - все.
Дальше в коде просто используете поля не заботясь о проверках.
Причем там можно делать что-то типо field: process.env.FIELD || 123
И у вас будут значения из переменных сред браться если нужно
И сервис возвращает один из этих обьектов в зависимости от переменных - все.
Дальше в коде просто используете поля не заботясь о проверках.
Причем там можно делать что-то типо field: process.env.FIELD || 123
И у вас будут значения из переменных сред браться если нужно
LL
как говаривал один мой препод : на пятерку даже я не знаю - это кто профессионалом захочет назваться))) а так то Метархия это перспективное направление мета программирования и передовая архитектура - то что там говориться будет реализовано уже в ближайшее время
M
я имел в виду с какого уровня в патреоне досутпны видео)
АБ
Подход интересный, у меня на работе такой же, но не очень удобный, потому что становится не очень прозрачно откуда какие переменные будут приходить в конкретный момент. Особенно с учётом того, что часть будет опционально из env залетать.
АБ
Хотя если конфигов штуки 2, то все ок.
А
в целом идея понятна, наверно я просто не любитель таких подходов.
МЗ
Ну я в пет проектах просто .env кладу и все нужный
А когда есть штук 5 разных проектов одновременно, в каждом 3-4 окружения и по 40-50 настроек то там этот подход тупо спасает
А когда есть штук 5 разных проектов одновременно, в каждом 3-4 окружения и по 40-50 настроек то там этот подход тупо спасает
А
вот у меня сейчас в монорепе 6 проектов, я просто завёл под каждый проект sh скрипт который нужные настройки в терминал подгружает. dotenv уже не поможет.