aslain.dev
0%
01 Hizmetler 02 Hakkımda 03 Projeler 04 Stack 05 Blog 06 İletişim
← Tüm makaleler Webontwikkeling

PHP Composer: praktische gids voor dependency-beheer

PHP Composer is de ruggengraat van moderne PHP-ontwikkeling: een dependency-manager die de bibliotheken downloadt die je project nodig heeft, hun versies beheert en je klassen automatisch laadt. Wat NPM voor JavaScript doet, doet Composer voor PHP. In deze gids behandelen we alles wat je dagelijks nodig hebt — van het installeren van Composer tot het toevoegen van pakketten met require, en van de logica achter composer.lock tot PSR-4-autoloading — met echte, werkende voorbeelden.

Wat is Composer en waarom heb je het nodig?

Vroeger betekende het gebruiken van een PHP-bibliotheek dat je bestanden met de hand downloadde en ze één voor één met require binnenhaalde. Die aanpak was foutgevoelig en maakte versie-upgrades tot een nachtmerrie. Composer lost drie kernproblemen op:

  • Dependency-resolutie: het vindt automatisch de andere pakketten die een pakket nodig heeft (en hun dependencies) en installeert compatibele versies.
  • Versiebeheer: jij bepaalt welke versies acceptabel zijn, en Composer kiest de beste die aan die regel voldoet.
  • Autoloading: het laadt je klassen en pakketten op naam, zonder dat je elk bestand handmatig hoeft te require-en.

Pakketten worden opgehaald uit een centrale repository genaamd Packagist (packagist.org). Het hele ecosysteem — Laravel, Symfony, Guzzle, PHPUnit — wordt daarvandaan gedistribueerd.

Installatie en je eerste project

Je kunt Composer installeren afhankelijk van je besturingssysteem: er is een officieel installatiescript voor Linux/macOS en een kant-en-klare installer voor Windows. Om de installatie te controleren:

composer --version

Bij het starten van een nieuw project kun je een interactieve wizard uitvoeren of direct een composer.json genereren:

composer init

Deze opdracht vraagt naar de pakketnaam, beschrijving, licentie en eerste dependencies, en maakt vervolgens een composer.json-bestand in de hoofdmap. Dat bestand is het identiteitsbewijs van je project; dependencies, autoload-regels en metadata staan er allemaal in.

Pakketten installeren: require en install

De meest directe manier om een pakket toe te voegen is de opdracht require. Bijvoorbeeld, om de populaire HTTP-client Guzzle te installeren:

composer require guzzlehttp/guzzle

Dit downloadt het pakket, voegt het toe aan composer.json, werkt composer.lock bij en plaatst het in de map vendor/. Je kunt ook een versiebeperking vastleggen:

composer require guzzlehttp/guzzle:^7.5

Voeg tools die alleen tijdens ontwikkeling nodig zijn (testbibliotheken, code-analysers) toe met --dev; deze worden uitgesloten van productie-installaties:

composer require --dev phpunit/phpunit

Wanneer je een project kloont, gebruik je install om de dependencies op te zetten. Deze opdracht leest de exacte versies uit composer.lock en installeert ze letterlijk:

composer install

Op een productieserver is de gangbare combinatie om ontwikkel-dependencies over te slaan en de autoload te optimaliseren:

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

composer.json versus composer.lock

Het door elkaar halen van de rollen van deze twee bestanden is de meest voorkomende bron van verwarring. composer.json beschrijft je intentie: "elke 7.x-versie van Guzzle is prima". composer.lock legt de huidige realiteit vast: "Guzzle 7.8.1 is geïnstalleerd, precies". Een typische require-sectie ziet er zo uit:

{
    "require": {
        "php": "^8.2",
        "guzzlehttp/guzzle": "^7.5",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    }
}

De betekenis van de versie-operatoren is cruciaal:

  • ^7.5 — 7.5 en hoger, maar lager dan 8.0. De meest gebruikte "sta compatibele updates toe"-operator.
  • ~7.5 — 7.5 en hoger, maar lager dan 7.6 (alleen patch-releases).
  • 7.5.* — elke patch in de 7.5-serie.

Gouden regel: voeg composer.lock altijd toe aan versiebeheer (Git). Zo installeert iedereen in het team en de productieserver dezelfde versies, wat "het werkte op mijn machine"-problemen voorkomt.

Wanneer update of install gebruiken?

Het onderscheid tussen de twee vormt de kern van dependency-beheer. composer install blijft trouw aan het lock-bestand en wijzigt geen versies. composer update upgradet pakketten naar de nieuwste compatibele versies die composer.json toestaat en herschrijft composer.lock:

composer update

Wil je slechts één pakket bijwerken, noem het dan:

composer update monolog/monolog

Voer composer update nooit uit op een productieserver. Omdat die opdracht versies wijzigt, kan ze onverwachte breuken veroorzaken in een live-omgeving. Doe de update lokaal, test hem, commit de nieuwe composer.lock, en draai op de server alleen composer install.

Autoloading: je eigen klassen met PSR-4

De krachtigste functie van Composer is autoloading. Om Composer ook je eigen klassen te laten laden, voeg je een PSR-4-mapping toe aan composer.json. Dit koppelt een namespace-prefix aan een map:

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

Deze mapping betekent: de klasse App\Services\Mailer wordt opgezocht in src/Services/Mailer.php. Na het toevoegen van de mapping moet je de autoload-map opnieuw genereren:

composer dump-autoload

Nu is één regel op het toegangspunt van je project genoeg. Door de door Composer gegenereerde autoloader in te sluiten, worden zowel je eigen klassen als alle pakketten automatisch geladen:

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

use App\Services\Mailer;

$mailer = new Mailer();

Voor prestaties in productie berekent de vlag --optimize-autoloader (of -o) de klasse-naar-bestand-mapping vooraf, waardoor zoekopdrachten in het bestandssysteem tijdens runtime wegvallen.

Automatisering met Composer-scripts

Met de sectie scripts in composer.json kun je snelkoppelingen definiëren voor opdrachten die je vaak uitvoert:

{
    "scripts": {
        "test": "phpunit",
        "check": [
            "@php -l src/",
            "phpunit"
        ]
    }
}

Je voert ze uit met composer test of composer check. Event-hooks zoals post-install-cmd worden ook gebruikt om automatische taken na de installatie te starten — Laravel die na de setup een sleutel genereert is een voorbeeld.

Veelgestelde vragen

Moet ik composer.lock in Git committen?

Ja, absoluut. In applicatieprojecten moet composer.lock altijd gecommit worden; dit garandeert dat elke ontwikkelaar en de productieserver exact dezelfde versies installeren. Alleen als je een bibliotheek (een pakket) voor anderen bouwt, is het een gangbare keuze om composer.lock niet te committen.

Ik krijg een "Class not found"-fout — waarom?

De meest voorkomende oorzaak is een verouderde autoload-map. Als je een nieuwe PSR-4-namespace hebt toegevoegd of bestanden/mappen hebt hernoemd, voer dan composer dump-autoload uit. Zorg er ook voor dat de namespace exact overeenkomt met het bestandspad en de klassenaam, inclusief hoofdletters.

Wat is het verschil tussen require en require-dev?

require bevat pakketten die de applicatie in elke omgeving nodig heeft om te draaien. require-dev bevat tools die alleen tijdens ontwikkeling nodig zijn (PHPUnit, statische analyse, debuggers). In productie slaat composer install --no-dev die ontwikkel-dependencies over, waardoor de installatie lichter en veiliger wordt.

Is het dependency-beheer in je PHP-project een wirwar geworden? Als je hulp nodig hebt met Composer-installatie, autoload-configuratie, versieconflicten of een schone architectuur voor een op Laravel/Symfony gebaseerd project, neem dan contact met me op — laten we samen een stevige basis voor je project leggen.

Bu kategorideki tüm yazılar →

Devamı için