builtin server read environment variables file

[JohnRDOrazio]

Description

If the builtin server (php -S localhost:PORT) could automatically detect environment variable files such as .env, .env.development and load the key => value pairs such that they are then available in the $_ENV magic variable array, it would make local development much easier and more similar to other languages such as node or ruby.

Say I spawn the bultin server for a local API backend on port 8000. Then I want to spawn another builtin server for a frontend, which however knows nothing about which port the API backend is being served on. If I could place an environment variable file in my frontend project .env.development with API_PORT=8000, the frontend could then have $_ENV['API_PORT'] with a value of 8000 and I could use that in my frontend logic to determine how the frontend should interface with the API backend.

I might add, that spawning a localhost instance with the builtin server could also automatically set an environment variable of $_ENV['development']=true.

Docker, React and NextJS all follow similar patterns of loading environment variables from .env files:

• https://create-react-app.dev/docs/adding-custom-environment-variables/
• https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables
• https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables/

It would be great if the PHP builtin server could follow a similar pattern, making PHP development more user / development friendly.

[JohnRDOrazio]

Ruby has a similar mechanism with the dotenv ruby gem https://github.com/bkeepers/dotenv .

[JohnRDOrazio]

I'm seeing there is a composer package that can be used to obtain this (https://github.com/vlucas/phpdotenv - https://packagist.org/packages/vlucas/phpdotenv), however it would be a nice convenience if at least a base environment variable along the lines of $_ENV['APP_ENV'] with a value along the lines of development were automatically created by the builtin server.

[iluuu1994]

Hi @JohnRDOrazio!

I'm not sure it makes sense to implement a feature the application depends on solely in the built-in web server. When you're ready to push to production, you will need to remember that the environment that .env parsing will not work there, and to bundle a library that will do it for you. But if that's necessary, why not just do that in the first place? There's https://symfony.com/components/Dotenv, https://github.com/vlucas/phpdotenv and many more. I could see a stronger argument to implement this as a general feature of PHP, but I'd consider this a solved problem.

If you still think that this is something PHP would benefit from, please send an e-mail to the internals mailing list to pitch your idea, so we can see if that's something people would like to see. You'll also need to elaborate in a bit more detail how this feature would work (i.e. with which SAPIs, when they are loaded, whether they are cached, etc.).

[JohnRDOrazio]

in fact I don't think that the environment files are quite as necessary for production, since in production you would generally be using a full fledged server such as Apache or Nginx. But since the built-in server is quite useful for localhost development and testing, without requiring Apache or Nginx, I see it more as a feature than a bug to make local development more user friendly, if the built-in server automatically creates a "development" environment by automatically creating a development environment variable, similar to how other frameworks work. I already have logic in place in my application to detect whether we are on localhost or in production, so I'm not worried about .env files not working in production (I don't currently use any .env files in production). In any case I will send an email on the mailing list to see if anyone else is interested in such a feature.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.