Slik får du kontroll på PHP-prosjekter med Composer uten å miste oversikten

Mange PHP-prosjekter starter små, med noen få filer og kanskje et rammeverk. Etter hvert kommer biblioteker, dev-verktøy, testverktøy og scripts, og til slutt føles alt skjørt og uoversiktlig.

Composer er limet som holder et moderne PHP-prosjekt sammen, men for mange fremstår det som litt magisk. Her ser vi på en praktisk måte å bruke Composer slik at du kan jobbe tryggere og mer strukturert med avhengigheter og verktøy.

Hva Composer faktisk gjør i et prosjekt

Composer er i praksis et prosjektspesifikt verktøy for å:

• Definere hvilke pakker prosjektet trenger
• Installere riktig versjon av hver pakke
• Låse avhengighetene slik at hele teamet får samme oppsett
• Gi deg en felles inngang til CLI-verktøy viacomposer scripts

Nøkkelen er å forstå samspillet mellomcomposer.json,composer.lockogvendor-mappen. Da blir også feilsøking mye enklere.

composer.json, composer.lock og vendor: hvem gjør hva?

composer.jsoner oppskriften. Her sier du hvilke pakker du ønsker, hvilke PHP-versjoner som støttes, og hvilke scripts som kan kjøres. Dette er filen du normalt redigerer selv.

composer.locker fasiten. Denne filen inneholder eksakte versjoner av alle pakker og deres avhengigheter slik de var installert sist. Den bør alltid sjekkes inn i Git for applikasjoner, slik at alle får samme miljø.

vendor-mappen er selve leveransen. Her ligger den faktiske koden til pakkene. Denne mappen skal normaltikkesjekkes inn i Git, siden den kan gjenopprettes fra composer.lock.

En praktisk tommelfingerregel: redigercomposer.json, kjør Composer-kommandoer, commitcomposer.lock, ignorervendori .gitignore.

Sett opp et ryddig prosjekt med Composer fra starten

La oss si du starter et nytt prosjekt i en tom mappe. En vanlig arbeidsflyt kan være:

1. Initialiser Composer:composer init
2. Legg til rammeverk eller bibliotek: for eksempelcomposer require slim/slim
3. Legg til utviklingsverktøy: for eksempelcomposer require –dev phpunit/phpunit
4. Definer scripts som kapsler inn kommandoer du bruker ofte

Et enkelt utdrag fra en fornuftigcomposer.jsonkan se slik ut (forkortet for tydelighet):

Eksempel:

{
"require": {
"php": "^8.1",
"slim/slim": "^4.0"
},
"require-dev": {
"phpunit/phpunit": "^10.0"
},
"scripts": {
"test": "phpunit --configuration phpunit.xml",
"cs-fix": "php-cs-fixer fix"
}
}

Forstå versjonsstrenger og hvorfor de betyr noe

Composer bruker semantisk versjonering, og versjonsstrengene har stor betydning for hvor stabilt prosjektet ditt blir over tid. Noen typiske mønstre:

• ^1.4: oppdaterer automatisk til siste minor og patch, men ikke til 2.x
• ~1.4: litt strengere, holder seg innenfor 1.4.x
• 1.4.2: eksakt versjon, ingen automatikk

For applikasjoner er det ofte fornuftig å være litt konservativ med kritiske rammeverk, men mer fleksibel med små hjelpepakkker. Målet er å slippe overraskelser når du kjørercomposer update.

composer install vs composer update i hverdagen

Disse to kommandoene skaper mye forvirring, men de gjør forskjellige ting og bør brukes forskjellig i et team.

composer installbrukercomposer.lockog installerer nøyaktig de versjonene som står der. Dette er kommandoen du bør kjøre på nye maskiner, i CI og på servere.

composer updateignorerer eksisterende låsfil, finner nye versjoner innenfor reglene i composer.json og oppdaterer både vendor og composer.lock. Dette bør du normalt gjøre lokalt, kanskje på en dedikert gren, og så committe endringene.

En enkel huskeregel:installfor å få samme oppsett som resten,updatefor å endre oppsettet.

Bruk scripts til å samle verktøy på ett sted

Et kraftig, men ofte underbrukt, område i Composer erscripts. I stedet for å huske lange kommandoer kan du definere aliaser som hele teamet deler.

Noen praktiske eksempler:

• test: kjører PHPUnit med standardoppsett
• lint: kjører PHP CodeSniffer eller PHPStan
• check: kjører både tester og statisk analyse

Da kan du kjørecomposer testellercomposer checkuansett om verktøyene ligger globalt eller i vendor/bin, og samme kommando fungerer i CI. Det gjør det også mye enklere for nye utviklere å komme i gang.

Vanlige feil og hvordan du raskt feilsøker dem

Noen typiske problemer går igjen i Composer-baserte prosjekter. Her er noen korte sjekkpunkter du kan gå gjennom før du begynner å lete mer bredt.

• “Class not found”: sjekk atvendor/autoload.phpinkluderes, og atautoload-delen i composer.json stemmer med mappestruktur. Kjørcomposer dump-autoloadved behov.
• Konfliktmeldinger ved install: les toppen av feilmeldingen først, der står ofte hvilke to pakker som krasjer, og hvilke versjonskrav som er umulige å kombinere.
• Ulik oppførsel lokalt og i CI: kontroller PHP-versjon og at begge miljøer brukercomposer installmed samme composer.lock.

Hvis prosjektet har levd lenge og mye rart har skjedd, kan du av og til rydde opp ved å slette vendor-mappen og kjørecomposer installpå nytt. Bare sørg for at composer.lock ligger i Git først.

En liten sjekkliste for robuste Composer-prosjekter

For å avslutte, her er en kort sjekkliste du kan bruke når du setter opp eller overtar et PHP-prosjekt:

• composer.json er lesbar, med tydelig skille mellomrequireogrequire-dev
• composer.lock er sjekket inn i Git for applikasjoner
• vendor-mappen er ignorert i .gitignore
• Scripts definerer vanlige kommandoer for test, kvalitet og deploy
• Alle i teamet forstår forskjellen påinstallogupdate
• Autoload-oppsettet er testet med en enkel “hello world” fra src-mappen

Med disse grunnprinsippene på plass blir Composer mindre magi og mer et pålitelig verktøy du kan lene deg på i hverdagen. Det gir tryggere deploys, færre overraskelser og enklere samarbeid rundt PHP-kode.