Comments 9
В текущий реалиях новости о Шторме как то кажутся чуточку бесполезными после аннулирование купленных ранее лицензий.
Схема работы довольно бессмысленная и я пока не встречал её использование в реальной продуктовой разработке. Так или иначе, каждый её переделывал на более удобный вариант с игнором любого
.envфайла, где сам файл.envи был точкой истинности для определённого окружения, и выставляется (создаётся) отдельно на каждом из окружении руками.
Очень даже удобно, когда в `.env` видно какие локальные настройки можно переопределить. Если открыть хоть через 10 лет, не надо будет по всему коду искать, как же эта переменная называлась.
А настоящие настройки храню в `.env.local`, так что с "каждый её переделывал" вы погорячились ;)
Более того, я подобную схему использую не только в PHP - в vuejs тоже что то подобное по умолчанию
Согласен, чуть-чуть чувствуется что перегнул с иронией.
Однако не поверите - реально на каждом проекте (говорю про 3 разных, начиная с симфы 3.4, заканчивая 7.х) видел другую, где всё ровно наоборот: .env.example как шаблон, а .env уже реальные значения под гитигнором. Точно такая же схема и в ларке идёт по умолчанию. А оригинальную симфонёвую схему ни разу не встречал.
Ну с лары наверное эта привычка и перекочевала. Только непонятно зачем себе усложнять жизнь - symfony flex например пишет в .env умолчания с маркерами (чтобы почистить при удалении пакета) если есть в рецепте.
Ну не только лара, ещё раньше докер подхватывал env файл по дефолту в какой-то версии, а потом заменили на явное указание env_file секции с require: false, решения под ноду ещё. Рекомендации в Rails такие же. Да куча, подозреваю, решений, где рекомендуется именно использование файла .env для текущего окружения, а не его оверрайд.
Единственное исключение, которое я встречал (помимо дефолтов Symfony) - это Sentry, там .env по-дефолту, а для оверрайда предлагают использовать .env.custom.
Но в любом случае, по-мне, это примерно тоже самое как поставлять php.ini в качестве шаблона, а чтоб переопределить - надо создать файл php.local.ini. Странное решение.
P.S. Я уже признался, что погорячился. Можно списать на то, что автор дайджеста по симфе -- токсик и просто хейтит "непривычные для него решения")
Дело в том, что в symfony в .env не "шаблон", а реальные умолчания которые можно поменять не лазая по конфигам, а .env.* файлы его не заменяют, а дополняют. В отличии от ларовского .env.example
Но в любом случае, по-мне, это примерно тоже самое как поставлять
php.iniв качестве шаблона, а чтоб переопределить - надо создать файлphp.local.ini
Вы не поверите, но я примерно так и делаю ;)
Только опять же - не "в качестве шаблона", а как умолчания.
В докер образах например свои настройки (таймзону, может ограничения на память и загрузку файлов там) пихаю в $PHP_INI_DIR/conf.d/app.ini
Что то вроде
RUN ln -s $PHP_INI_DIR/php.ini-production $PHP_INI_DIR/php.ini
COPY docker/php/php.ini $PHP_INI_DIR/conf.d/app.ini
Это так называемый "debian way", когда основной файл конфигурации не надо трогать (чтобы при обновлении пакетов не было конфликтов), а свои настройки класть в директорию "*.d/" файлы из которой подключаются в основном конфиге.
Вы не поверите, но я примерно так и делаю ;)
Для докера я тоже, и строчки почти что полностью идентичные. :)
Однако описанный вами вариант не совсем тоже самое. Дефолты для env-переменных по-хорошему стоит хранить в параметрах по-моему:
parameters:
env(SOME_IS_ENABLED): '1'
app.some.is_enabled: '%env(bool:SOME_IS_ENABLED)%'
Так что .env как раз и выступает в роле оверрайда этих дефолтов, т.е. это и есть "свои настройки", которые и кладутся в проект для переопределения дефолтов.
Дайджест новостей по PHP, Symfony и Laravel за ноябрь'2024