Composer en dependency management in PHP uitgelegd

Als je serieus met PHP werkt, kun je niet om Composer en dependency management heen. Composer is de tool die PHP-development de laatste jaren fundamenteel heeft veranderd: van losse libraries handmatig downloaden en includen, naar een gestandaardiseerd ecosysteem waar je met één commando duizenden hoogwaardige packages kunt installeren.

In deze gids leer je wat Composer precies doet, hoe je het installeert en gebruikt, hoe autoloading werkt, en hoe je versies en dependencies professioneel beheert in je projecten.

Wat is Composer eigenlijk?

Composer is een dependency manager voor PHP. Vergelijkbaar met npm voor JavaScript of pip voor Python beheert Composer externe code (libraries, frameworks, tools) die jouw project nodig heeft om te draaien.

Zonder Composer zou je elke library handmatig moeten downloaden, updaten en includen. Met Composer definieer je je afhankelijkheden in één bestand, en een simpel commando regelt de rest.

Composer lost drie problemen op:

• Installatie en updates van externe code
• Versiebeheer, welke versie van welke library werkt samen?
• Autoloading, classes automatisch laden zonder require statements

Als je de basis van PHP al onder de knie hebt en met object-oriented code werkt, is Composer de logische volgende stap naar professionele PHP-ontwikkeling.

Composer installeren

Composer is beschikbaar voor Windows, macOS en Linux. Je installeert het globaal op je systeem, zodat je het overal kunt gebruiken.

macOS en Linux

Open een terminal en voer uit:

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Windows

Download de officiële installer van getcomposer.org en volg de stappen. De installer configureert automatisch je PATH.

Controleer of alles werkt:

composer --version

Je ziet nu de Composer-versie met datum. Zo niet, check dan of je PHP correct geïnstalleerd hebt, Composer heeft PHP 7.2.5 of hoger nodig.

Je eerste composer.json

Elk Composer-project heeft een composer.json bestand in de root. Dit is het manifest van je project: welke packages nodig zijn, welke PHP-versie vereist is, en hoe autoloading werkt.

Maak een nieuw project aan:

mkdir mijn-project
cd mijn-project
composer init

Composer stelt je interactief een aantal vragen (naam, beschrijving, author) en genereert een basis composer.json:

{
    "name": "sander/mijn-project",
    "description": "Een voorbeeldproject",
    "require": {
        "php": ">=8.2"
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

Dit bestand is het hart van dependency management in je project.

Packages installeren

Het PHP-ecosysteem draait om Packagist, de centrale repository waar duizenden packages beschikbaar zijn. Je installeert een package met het require commando:

composer require guzzlehttp/guzzle

Composer doet nu het volgende:

1. Zoekt de laatste stabiele versie van Guzzle op Packagist
2. Controleert of die versie compatibel is met je PHP-versie
3. Installeert Guzzle plus alle sub-dependencies in de vendor/ map
4. Werkt composer.json en composer.lock bij
5. Genereert een autoloader

Na installatie kun je Guzzle direct gebruiken in je code:

<?php

require __DIR__ . '/vendor/autoload.php';

use GuzzleHttp\Client;

$client = new Client();
$response = $client->get('https://api.example.com/data');

echo $response->getBody();

Geen handmatige require voor elke class, de autoloader regelt alles.

composer.json versus composer.lock

Na je eerste installatie verschijnt er een composer.lock bestand. Het verschil met composer.json is cruciaal om te begrijpen.

composer.json beschrijft welke versieranges je wilt:

{
    "require": {
        "guzzlehttp/guzzle": "^7.0"
    }
}

composer.lock legt vast welke exacte versies geïnstalleerd zijn:

{
    "packages": [
        {
            "name": "guzzlehttp/guzzle",
            "version": "7.8.1"
        }
    ]
}

Dit is belangrijk omdat:

• Op jouw machine werkt composer install → installeert precies de versies uit composer.lock
• Een collega voert composer install uit → krijgt exact dezelfde versies
• Je productieserver draait composer install → deployt met identieke dependencies

Commit altijd beide bestanden. De vendor/ map zet je in .gitignore.

Install versus update

Twee commando's die vaak verward worden:

• composer install, installeert exact wat in composer.lock staat
• composer update, zoekt nieuwe versies binnen je composer.json constraints en werkt de lockfile bij

Gebruik install op productie en CI. Gebruik update alleen bewust tijdens ontwikkeling wanneer je dependencies wilt upgraden.

Wil je één specifieke package updaten:

composer update guzzlehttp/guzzle

Versieconstraints begrijpen

Composer gebruikt semantic versioning (semver) om te bepalen welke versies acceptabel zijn. Een versienummer bestaat uit drie delen: MAJOR.MINOR.PATCH.

De meestgebruikte constraints:

De ^ (caret) is veruit de meest gebruikte en praktische optie. Het laat minor en patch updates toe (bugfixes en nieuwe features), maar voorkomt breaking changes.

Require-dev: development dependencies

Sommige packages heb je alleen nodig tijdens ontwikkeling, niet in productie. Denk aan testframeworks, debuggers of linters. Die installeer je met --dev:

composer require --dev phpunit/phpunit
composer require --dev phpstan/phpstan

Ze komen terecht in een aparte require-dev sectie:

{
    "require": {
        "guzzlehttp/guzzle": "^7.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^10.0",
        "phpstan/phpstan": "^1.10"
    }
}

Op productie installeer je vervolgens zonder dev-dependencies:

composer install --no-dev --optimize-autoloader

Dat scheelt schijfruimte en laadtijd.

Autoloading met PSR-4

Het échte voordeel van Composer is de autoloader. In plaats van overal require 'pad/naar/bestand.php'; te schrijven, worden classes automatisch geladen op basis van hun namespace.

PSR-4 is de standaard hiervoor. In je composer.json:

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

Dit mapt de namespace App\ naar de map src/. Als je nu een class App\Models\User maakt in src/Models/User.php:

<?php

namespace App\Models;

class User
{
    public function __construct(
        public string $name,
        public string $email
    ) {}
}

Kun je die direct gebruiken zonder require:

<?php

require __DIR__ . '/vendor/autoload.php';

use App\Models\User;

$user = new User('Sander', '[email protected]');

Na het wijzigen van je autoload-config voer je uit:

composer dump-autoload

Dit is een natuurlijke uitbreiding op wat je al weet over functies en scope: in plaats van handmatig files inladen, laat je Composer het werk doen op basis van namespaces.

Handige Composer commando's

Een overzicht van commando's die je dagelijks gebruikt:

• composer install, installeer dependencies uit lockfile
• composer update, update dependencies binnen constraints
• composer require <package>, voeg package toe
• composer remove <package>, verwijder package
• composer outdated, toon packages met updates beschikbaar
• composer show, lijst geïnstalleerde packages
• composer dump-autoload, regenereer autoloader
• composer validate, controleer syntax van composer.json
• composer audit, controleer op bekende security issues

Die laatste is sinds Composer 2.4 beschikbaar en zou onderdeel moeten zijn van elke CI-pipeline.

Scripts definiëren

Je kunt custom commando's definiëren in composer.json:

{
    "scripts": {
        "test": "phpunit",
        "analyze": "phpstan analyse src",
        "check": [
            "@test",
            "@analyze"
        ]
    }
}

Vervolgens uitvoerbaar met:

composer test
composer analyze
composer check

Dit maakt je project direct bruikbaar voor iedereen, zonder dat ze de exacte commando's hoeven te onthouden.

Veelvoorkomende valkuilen

Een paar zaken waar beginnende Composer-gebruikers tegenaan lopen:

Vergeten composer.lock te committen. Zonder lockfile krijgt iedereen een andere versie. Commit altijd composer.json én composer.lock.

vendor/ wel committen. De vendor-map hoort in .gitignore. Die bevat honderden megabytes aan code die reproduceerbaar is via composer install.

composer update gebruiken op productie. Dit update versies en kan onverwacht nieuwe code introduceren. Gebruik altijd composer install --no-dev op productie.

Te losse versieconstraints. Gebruik ^ voor de meeste packages, niet * of >=1.0, om onverwachte breaking changes te voorkomen.

Autoloader niet optimaliseren op productie. Voeg --optimize-autoloader toe voor betere performance door class-maps te genereren.

Veelgestelde vragen

Wat is Composer in PHP?

Composer is de standaard dependency manager voor PHP. Het beheert externe libraries en hun versies voor je project, en zorgt automatisch voor autoloading van classes zodat je ze direct kunt gebruiken.

Wat is het verschil tussen composer.json en composer.lock?

composer.json definieert welke packages en versieranges je project nodig heeft, terwijl composer.lock de exacte versies vastlegt die daadwerkelijk geïnstalleerd zijn. Commit altijd beide bestanden in je repository.

Wanneer gebruik ik require en wanneer require-dev?

Gebruik require voor packages die nodig zijn in productie, zoals frameworks of libraries die je code daadwerkelijk gebruikt. Gebruik require-dev voor tools die je alleen tijdens ontwikkeling nodig hebt, zoals PHPUnit of PHPStan.

Moet ik de vendor map committen in git?

Nee, voeg de vendor map toe aan je .gitignore. Door composer.json en composer.lock te committen kan iedereen met composer install exact dezelfde dependencies installeren, wat je repository klein en reproduceerbaar houdt.

Wat is PSR-4 autoloading?

PSR-4 is een standaard die namespaces koppelt aan mappenstructuren. Composer gebruikt PSR-4 om automatisch classes te laden op basis van hun namespace, zodat je geen handmatige require-statements meer nodig hebt in je code.

Conclusie

Composer is geen optionele extra, het is de fundering van moderne PHP-ontwikkeling. Door dependencies expliciet te beheren, versies vast te leggen en autoloading te automatiseren, kun je je focussen op het bouwen van functionaliteit in plaats van het bijhouden van libraries.

Begin klein: initialiseer een project met composer init, installeer één package, en experimenteer met de autoloader. Vanuit daar bouw je een werkwijze op waarmee je professioneel met arrays, loops en variabelen en control flow kunt werken, gebaseerd op een solide fundament van herbruikbare, goed beheerde code.