A common practice when developing applications is to store some configuration
options as environment variables in a .env
file (pronounced "dot-env"). You
can already use this technique in Symfony applications, but in Symfony 3.3 we've
decided to make it a built-in feature thanks to the new Dotenv component.
In practice, the Dotenv component parses .env
files to make environment
variables stored in them accessible in your application via getenv()
,
$_ENV
or $_SERVER
. If your .env
file contains these variables:
1 2
DB_USER=root
DB_PASS=pass
The following code will parse them and turn them into environment variables:
1 2 3
use Symfony\Component\Dotenv\Dotenv;
(new Dotenv())->load(__DIR__.'/.env');
Now you can get the database password in your application as follows:
1
$dbPassword = getenv('DB_PASS');
In addition to loading the variables, you can just parse them because the component defines three stages: load, parse, and populate.
Before creating a new component, we reviewed the existing libraries that provide similar features, but none of them matched our specific set of requirements:
- Variables should not be validated in any way (because the real environment variables can only be strings and you can't validate them).
- The component provides a strict implementation of what you can do in a real
bash shell script and nothing more:
$VAR
and${VAR}
are supported, you can concatenate strings, execute commands and store the result in a variable, etc. - Superb error messages to easily spot any issue.
- Clean and minimal API, without unneeded abstractions like being able to add an
environment variable directly (just use
putenv()
).
Will this in Symfony flex also replace the app / app_dev.php usage? and use something like:
$kernel = new AppKernel(getenv('SYMFONY_ENV') ?: 'prod', getenv('SYMFONY_DEBUG') ?: false);
Awesome! Thank you for this!
Will this have any effect on the feature described here: http://symfony.com/blog/new-in-symfony-3-2-runtime-environment-variables ?
Will they work seamlessly together ? Or will there will be some conflict if I have variable "ABC" defined both as environment variable AND in the ".env" file ?
Thanks.
Hello and thanks for starting this useful component! I'm looking forward to using it and this could be a case for another best practice (replacing the parameters.yml file with environment variables).
You wrote "You can already use this technique in Symfony applications", but I haven't found anything about the possibility to use a .env file in the official documentation or blog.
@Cristi I meant that nothing in Symfony prevents you from using one of the existing libraries to load the .env files and use those values in the config files (with the %env()% syntax). But it won't be a seamless experience as the one provided by this new component.
Does this effectively kill off the vlucas/phpdotenv package? Why not just work with the original author?
@Sam I've explained some reasons in the related PR. I started working on patching vlucas package, but the more I fixed things, the more my code was looking different. At some point, the approach was so radically different that trying to change vlucas's code didn't make sense anymore.
@Fabien thanks for the reply! Does this get used in the actual framework at all? Or is it kind of like an opt-in where you'd add it to app[_dev].php?
Also, is this a step towards removing parameters.* files? (finally!)
For anyone else hunting, the PR is here: https://github.com/symfony/symfony/pull/21234
@SamJarrett FYI: The PR number and link related to the new feature is always at the top of the blog post, next to the "Contributed by [author]" text, in the yellow box.
Awesome ! Good new component.
+1