Running PHP: CLI, Built-in Server, php.ini and Composer

Tools you use every day

PHP runs in several SAPIs (server APIs): the CLI for scripts, workers and tests (php script.php); PHP-FPM (FastCGI Process Manager) behind NGINX or Apache in production; and the built-in web server (php -S localhost:8000 -t public) for local development only. Configuration lives in php.ini; php --ini shows which files are loaded and php -m lists extensions such as pdo_pgsql, mbstring, intl and opcache. In development, enable display_errors and error_reporting = E_ALL; in production, log errors instead of displaying them. Composer manages dependencies and autoloading: composer init creates composer.json, composer require vendor/package adds a dependency, composer.lock pins exact versions (commit it), and vendor/autoload.php loads classes automatically. Use composer install in deployments to install exactly what the lock file says, and composer update deliberately when you want newer versions. Docker images such as the official php:8.x-fpm are a common way to keep versions consistent across machines.

A typical project start

Composer project, PSR-4 autoloading and the built-in server for development.

php -v                              # check the version
php -m | grep -i -E 'pdo|mbstring|intl|opcache'

mkdir shop && cd shop
composer init --name=acme/shop --type=project --no-interaction
composer require monolog/monolog
composer require --dev phpunit/phpunit phpstan/phpstan

# composer.json autoload section, then: composer dump-autoload
# "autoload": { "psr-4": { "Shop\\": "src/" } }

php -S localhost:8000 -t public     # development server only, never production

A kitchen with a pantry list

composer.json is your shopping list ("some flour, version 2 or newer"); composer.lock is the receipt saying exactly which brand and pack you bought. Every cook who uses the receipt ends up with identical ingredients.

Quick check: Why should composer.lock be committed to version control for applications?

• It contains your source code
• Composer cannot run without Git
• It stores database passwords
• It pins exact dependency versions so every environment installs the same packages