📦 Dependency Management with Composer

Why Composer Exists

Before Composer (which arrived in 2012), adding a library to a PHP project meant downloading a zip, extracting it somewhere, and hand-writing require statements — then repeating that for every library that library depended on. Get one version wrong and things broke in mysterious ways. This tangle has a name: dependency hell.

Composer replaces all of that. You declare what you need in one file, run one command, and Composer resolves the entire dependency graph, downloads the right versions, and generates an autoloader so you never write a require for a library again.

Installing Composer

Composer is a single executable. On Windows, the easiest route is the official installer, which also wires up your PATH:

# Windows: download and run Composer-Setup.exe from getcomposer.org

On macOS and Linux, download and verify the installer, then move it somewhere on your PATH so composer works from any folder:

# Download the installer
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

# Run it, then make it globally available
php composer-setup.php
sudo mv composer.phar /usr/local/bin/composer

# Clean up and verify
php -r "unlink('composer-setup.php');"
composer --version    # expect Composer 2.x

Anatomy of composer.json

The composer.json file is the heart of every Composer project. You can generate one interactively with composer init, or write it by hand. Here's a well-formed example, annotated:

{
    "name": "raydelapaz/demo-app",
    "description": "A small demo project",
    "type": "project",
    "license": "MIT",
    "require": {
        "php": "^8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "App\\Tests\\": "tests/"
        }
    },
    "config": {
        "sort-packages": true
    }
}

The commands you'll use daily

# Add a runtime dependency (edits composer.json + installs it)
composer require monolog/monolog

# Add a dev-only dependency
composer require --dev phpunit/phpunit

# Install everything listed (uses composer.lock if present)
composer install

# Update packages to newer allowed versions (and rewrite the lock)
composer update

# Remove a package
composer remove monolog/monolog

# Check for known security advisories in your dependencies
composer audit

Version Constraints

Composer follows Semantic Versioning: a version like 3.5.2 is MAJOR.MINOR.PATCH. Major bumps may break your code; minor bumps add features compatibly; patch bumps fix bugs. Constraints tell Composer which versions are acceptable.

composer.json vs. composer.lock

These two files work as a pair, and understanding the difference is what separates confident developers from confused ones.

Here's why the lock file matters: your composer.json might say ^3.0, which could mean 3.0.0 today and 3.9.5 next month. Without a lock file, your laptop, a teammate's machine, and the production server could each install different versions — the definition of "works on my machine." The lock file pins the exact version everyone gets.

Autoloading with PSR-4

Composer's autoloader is arguably its best feature. Instead of manually require-ing every file, you include one line and PHP loads classes on demand — for both third-party packages and your own code.

<?php
// One line, at the top of your entry point:
require __DIR__ . '/vendor/autoload.php';

// Now any installed class just works, no manual require:
use Monolog\Logger;
use Monolog\Handler\StreamHandler;

$log = new Logger('app');
$log->pushHandler(new StreamHandler(__DIR__ . '/app.log'));
$log->info('It works!');

Autoloading your own classes (PSR-4)

PSR-4 maps a namespace prefix to a directory. With this in composer.json…

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

…the namespace App\ points at the src/ folder. So the class App\Services\Mailer must live in src/Services/Mailer.php. The mapping is purely by convention — get the folder and file names right and it just works:

<?php
// File: src/Services/Mailer.php
declare(strict_types=1);

namespace App\Services;

class Mailer
{
    public function send(string $to, string $subject): bool
    {
        // ... real sending logic ...
        return true;
    }
}

<?php
// File: index.php
require __DIR__ . '/vendor/autoload.php';

use App\Services\Mailer;

$mailer = new Mailer();          // autoloaded from src/Services/Mailer.php
$mailer->send('ada@example.com', 'Hi');

Composer Scripts

Composer can run named shortcuts for common tasks — testing, linting, starting a dev server — so your whole team invokes them the same way. Define them under scripts:

{
    "scripts": {
        "start": "php -S localhost:8080 -t public/",
        "test": "phpunit --colors=always",
        "lint": "phpcs --standard=PSR12 src/",
        "check": [
            "@lint",
            "@test"
        ]
    }
}

# Run any script by name:
composer start        # launches the dev server
composer test         # runs the test suite
composer check        # runs lint, then test (a script that calls scripts)

# Pass extra arguments after --
composer test -- --filter MailerTest

Composer also fires scripts on lifecycle events. For example, post-install-cmd runs after composer install — handy for copying a default .env file so a fresh checkout is ready to go:

{
    "scripts": {
        "post-install-cmd": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ]
    }
}

Hands-on Exercise

<?php
// File: src/Activity.php
declare(strict_types=1);

namespace App;

use Monolog\Logger;
use Monolog\Handler\StreamHandler;
use Monolog\Level;

class Activity
{
    private Logger $log;

    public function __construct(string $file = 'activity.log')
    {
        $this->log = new Logger('activity');
        $this->log->pushHandler(new StreamHandler($file, Level::Info));
    }

    public function record(string $message): void
    {
        $this->log->info($message);
    }
}

<?php
// File: index.php
require __DIR__ . '/vendor/autoload.php';

use App\Activity;

$activity = new Activity(__DIR__ . '/activity.log');
$activity->record('User signed in');
$activity->record('User viewed dashboard');

echo "Logged! Check activity.log\n";

Summary & Quiz

📚 Further Reading

• Composer Documentation
• Packagist — the PHP package registry
• Semantic Versioning specification
• PSR-4 Autoloading Standard

🚀 What's Next?

You now have the full backend toolkit: the PHP language, a working environment, and Composer for pulling it all together. Next you'll put every piece to work in the Weekend Project — a hands-on build that ties the module's backend fundamentals into one small application.