On the Symfony blog they've made a post about a change in all Symfony versions around how .env files are handled and what prompted the change.

When Symfony 4.0 was released, the .env file was introduced as a way to set environment variables. The core of the system has not changed. But, thanks to recent updates to some core Symfony recipes, .env loading has some new features that can be enjoyed on any Symfony Flex project!

If you have an existing Symfony app (started before today), your app does not require any changes to keep working. But, if/when you are ready to take advantage of these improvements, you will need to make a few small updates.

The post outlines what changed exactly including the removal of the .env.dist, allowing a .env.local to override the settings and that the .env file is now pulled in for testing. The final point is the main reasoning for the changes to make testing much easier when it relies on these environment variable values. It doesn't require any changes to your current application but can be optionally implemented to take advantage of these updates.

On the Jolicode Blog there's a new post covering something not often mentioned in PHP development: environment variables. In this tutorial the author provides what you "need to know" about these variables and how to more effectively use them in your applications.

Environment variables for configuration are today’s best practice for application setup – database credentials, API Keys, secrets and everything varying between deploys are now exposed to the code via the environment, instead of configuration files or worse, directly hard-coded. Let’s dive into: how does it work, is it really a good idea, how to deal with them in PHP and finally some recommendations and common errors to avoid – with some real world traps we fell into!

They start with a "101" look at environment variables, covering what they are and how they can be referenced from your code (both in the web server and on the command line). They briefly talk about the potential danger in their use and using a .env file to store and read them rather than having them as web server configuration options. The post also includes examples of importing these values using various libraries and some of the common pitfalls that can come with their use.

In this post to his site Matt Stauffer shows a more real-word example of how the phpdotenv library can make configuration of your application simpler. He shows how it can be applied to a Craft CMS installation to manage domain-specific configuration details.

Craft is a fantastic CMS, but every CMS shows some pain points when you have a large team working on the same site at the same time. One of these points for me is Craft's native multi-environment configuration options, which allow you to define configuration options based on the domain name.

[...] This is great, but it's limited: You're hard-coding the configuration details into your code, which sometimes means putting sensitive information into your version control. Every developer's local installs either all have to have different domains, or if they use the same domain they need to all have the same configuration settings. And something just feels dirty about the codebase having such knowledge of every place it's going to be deployed.

He introduces the phpdotenv library and how you define its simple .env file with a basic INI structure. He then shows how to add the phpdotenv library to your installation:

• adding it to the list of Composer installed libraries
• update your front controller to load the configuration
• define the .env file with your settings
• ignore it via .gitignore

With these steps in place you can then update the Craft configuration with calls to getenv in all the right places to pull items from the phpdotenv configuration.

Sean Coates has posted a reminder for PHP developers (and really anyone executing command-line scripts) to use "env" instead of hard-coding the path to the PHP interpreter.

These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.