Greetings, I have recently started using the great feature of the built-in server for local development of an API that I have created from scratch, and a frontend that can interface with the API. Having a ready server makes development so much easier for a wider community of developers, without requiring to have a local Apache or Nginx. I even recently discovered the great feature that was introduced in PHP 7.4 PHP_CLI_SERVER_WORKERS, which I sorely needed because my API makes a couple of requests internally to various paths of the API, and nested requests require more than one process / worker, which wasn’t a problem for the Nginx / Apache production server but would have been a problem on localhost using the built-in server if it weren’t for this environment variable.
Seeing I have a number of people interested in contributing to the project, they have been asking me how they can develop on localhost without the trouble of setting up a whole WAMP environment. Having dabbled a bit in Docker and Ruby and Node and React, I have seen how streamlined the local development process is, because if you have any dotenv files they will be automagically read and loaded into the server environment. So you can have an environment file for local developement .env.development and another environment file for a production instance .env.production, and the application logic can detect whether it’s running on a development server or on a production server.
One of the nice features of React and frameworks that build off of React (such as Create React App or the more recent NextJS) is that they automatically create an environment variable of process.env.NODE_ENV with a value of development when you are running on localhost. I think it would be a nice feature of PHP’s built-in server to do something similar, automatically provide a $_ENV[APP_ENV] variable with a value of development so that the application logic knows whether it’s running on a localhost development environment rather than on a production server.
Ruby doesn’t have this functionality built-in, you need to require the dotenv-rails ruby gem, but it really does make the development process so much more user friendly. Instead, Docker and React provide this feature automatically.
In my use case, I have an API backend that I can spin up with php -S localhost:8000. Then when I spin up the frontend (which is also written in PHP), it knows nothing about where to find the API backend. On the production server, I had the host hardcoded into the frontend application. But if I want to be able to dynamically switch between localhost and production, I need to be able to instruct the frontend of where to find the API backend. This can easily be achieved through dotenv files, and even better if we have an automatic environment variable of $_ENV[APP_ENV]=development. I see that there is a composer package (GitHub - vlucas/phpdotenv: Loads environment variables from `.env` to `getenv()`, `$_ENV` and `$_SERVER` automagically.) that can achieve loading dotenv files, but other than loading dotenv files by means of a composer package it would be nice if we could at least have an automatic environment variable of $_ENV[APP_ENV]=development created by PHP’s built-in server. Seeing that the built-in server will pretty much always be used for easy localhost development, I don’t see any reason why a development environment variable couldn’t or shouldn’t be created by the built-in server? It would make PHP localhost development that much more user friendly in my opinion…
Here for example is the Create React App documentation page about environment variables Adding Custom Environment Variables | Create React App :
By default you will have NODE_ENV defined for you, and any other environment variables starting with REACT_APP_.
There is a built-in environment variable called NODE_ENV. You can read it from process.env.NODE_ENV. When you runnpm start, it is always equal to ‘development’, when you runnpm testit is always equal to ‘test’, and when you runnpm run buildto make a production bundle, it is always equal to ‘production’. You cannot override NODE_ENV manually. This prevents developers from accidentally deploying a slow development build to production.
Similarly NextJS Configuring: Environment Variables | Next.js :
Next.js has built-in support for loading environment variables from .env* files into
process.env.
And process.env.NODE_ENV is automatically set to development when running next dev; to test when running next test; and to production when running next build or next start.
I believe having similar functionality with PHP’s built-in server can make it more user / developer friendly to folks who are used to working with Docker or Node or Ruby.
John R.D.