Composer script to handle .env
file maintenance, based upon the concept of the popular incenteev/composer-parameter-handler package.
First you must require the package:
$ composer require yannoff/composer-dotenv-handler
Then, set up your composer.json
accordingly, as in the following example:
...
"scripts": {
"post-install-cmd": "Yannoff\\DotenvHandler\\ScriptHandler::updateEnvFile"
}
...
Options may be passed via the extra
section of the composer.json :
"extra": {
"yannoff-dotenv-handler": {
// options here
}
}
Name | Default value | Description |
---|---|---|
file | .env | The name of the auto-generated dotenv file |
dist-file | .env.dist | The name of the template file (the dist file) |
keep-outdated | true | Keep values in the env file that are not anymore in the dist file |
behavior | normal | If set to flex, enable support for Symfony Flex applications (see next section for details) |
As of November 2018, the guys at Symfony decided to change radically how dotenv
files are handled in symfony applications.
A local temporary workaround could be to modify the composer.json
extra section as follow:
"extra": {
"yannoff-dotenv-handler": {
"file": ".env.local",
"dist-file": ".env"
}
}
Anyway this is not an acceptable solution, indeed the dotenv file name may vary from one deploy environment to another (test, staging, prod...): the composer.json
can't be committed as is.
So here comes the behavior option:
"extra": {
"yannoff-dotenv-handler": {
"behavior": "flex"
}
}
When in flex behavior mode, the script will build the dotenv file name automatically, based upon either the APP_ENV
or ENV
(in this order of preference) environment variable (will use local as default value, if not set) at runtime.
For example, issuing the following command in a terminal:
$ /usr/bin/env ENV=staging composer install
would result in having the following config values:
dist-file
:.env
file
:.env.staging
Licensed under the MIT Licence.