Composer - komplet oversigt over avancerede funktioner

Som du allerede ved, er [Composer] (https://getcomposer.org/) en robust pakke- og afhængighedsadministrator til PHP, hvor du på elegant vis kan administrere hundredvis af projekter på én gang og distribuere kode, når den er skrevet, til alle programmer samtidigt.

Denne vejledning tjener som en detaljeret og omfattende guide for udviklere. Vi vil dække alle vigtige avancerede teknikker til at arbejde med Composer og forklare de tekniske detaljer og relevante afhængigheder.

Installation af Composer

Uanset platformen downloader vi fra [det officielle Composer-websted] (https://getcomposer.org/).

Internt hentes PHP-filen composer-setup.php, som, når den køres i CLI-tilstand, kan installere Composer. Det er også vigtigt at vide, at Composer ikke fungerer uden PHP, så først skal du kontrollere, at du har PHP kørende på din computer (det skal kun være tilgængeligt for Terminal).

På Mac og Linux fungerer Composer lige efter installationen, og du skal blot kalde kommandoen composer -v for hurtigt at kontrollere, at Composer er installeret korrekt.

På Linux kan følgende kommando bruges til at installere: /usr/bin/php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

På Windows er det en god idé at installere værktøjet Git Bash for Windows, som giver dig mulighed for at åbne en særlig Terminal, der opfører sig næsten som Linux og giver dig mulighed for at arbejde i det samme miljø som på Linux.

Installationen til servere er den samme som i et lokalt miljø. Du skal blot sikre dig, at du har den korrekte version af PHP, som Composer bruger internt.

Tilgængelige kommandoer

Composer implementerer en række kommandoer.

Brugen er: composer <kommando>, for eksempel: composer update.

Oversigt for 1.10.0:

Oprettelse og definition af et projekt

Hvert projekt, der administreres af Composer, er defineret af en composer.json-fil i roden, som definerer alle afhængigheder. Filen kan oprettes enten manuelt for et eksisterende projekt eller automatisk, når du opretter et projekt.

Da alt i Composer er en pakke, kan selve projektet være baseret på en pakke. Så hvis du f.eks. opretter snesevis eller hundredevis af meget ens projekter, giver det mening at lægge deres grundlæggende konfiguration og struktur i en separat pakke, som installationen kan baseres på.

Et eksempel på en sådan pakke er min [Baraja Sandbox] (https://github.com/baraja-core/sandbox), som er baseret på ren Nette 3.0 og tilføjer en grundlæggende afhængighed til min [Package Manager] (https://github.com/baraja-core/package-manager), som jeg bruger til alle projekter og håndtering af afhængigheder i Nette-konfigurationen.

Sandkassen installeres derefter ganske enkelt med kommandoen:

$ composer create-project baraja/sandbox <your-project-name>

Baseret på projektnavnet opretter Composer automatisk en mappe til at installere projektet (kopier indholdet af pakken og installer afhængighederne).

I vendor-mappen administrerer Composer derefter alle pakkerne (deres fysiske filer er der) og genererer en autoload af klasser, som vi ideelt set sætter direkte ind i index.php som en linje:

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

// Selve programkoden

Installation af yderligere pakker og afhængigheder

I et funktionelt projekt kan vi meget nemt installere nye pakker og tilføje afhængigheder.

Der er 2 måder at gøre dette på:

• Med kommandoen composer require ...,
• Ved at tilføje en afhængighed direkte til filen composer.json i afsnittet require og derefter bruge kommandoen composer update.

Prøv f.eks. at installere PackageManager: composer require baraja-core/package-manager, eller Doctrine: composer require baraja-core/doctrine.

Hvis den valgte pakke ikke kan installeres, kan der spørges om specifikke årsager, og Composer vil opregne de afhængigheder, der forhindrer dette. Ofte er det nok at rette en afhængighed af en bestemt version eller fjerne inkompatibel kode. Du kan få detaljerede oplysninger ved at bruge kommandoen: composer why baraja-core/doctrine.

Opdatering af projekter og pakker

Et veldesignet projekt er udviklet således, at du nemt kan hente opdateringer over tid og altid har de nyeste versioner af alle pakker. Den største fordel er, at du får alle fejl rettet, ofte forbedringer af ydeevnen og masser af nye funktioner. Desuden vil den gradvise overgang gøre det mindre kompliceret at opdatere efter lang tid, da du løser problemerne løbende i mindre omfang og undgår inkompatibiliteter.

Du kan opdatere alle pakker og afhængigheder ved at bruge kommandoen composer update for at opdatere alle pakker og afhængigheder.

Selve opdateringsprocessen kan i nogle tilfælde mislykkes. Årsagen er normalt enten en brudt afhængighed eller en inkompatibel pakke.

For detaljerede oplysninger om, hvorfor en pakke ikke kan installeres, skal du bruge kommandoen: composer why-not baraja-core/doctrine. Hvis vi allerede har pakken, og kun den specifikke version ikke virker (den vil ikke installeres), kan vi også bede om den specifikke version: composer why-not baraja-core/doctrine:v1.0.20.

I filen composer.json kan vi også angive afhængigheden af en bestemt runtime. Dette er især nyttigt, når vi udvikler et projekt med flere personer og ønsker at kontrollere, at de har alle udvidelserne installeret.

Typisk kontrolleres versionen af PHP (skal være 7.1.0 eller nyere):

{
   "require": {
      "php": ">=7.1.0"
   }
}

Eventuelt andre systemudvidelser:

{
   "require": {
      "php": ">=7.1.0",
      "ext-json": "*",
      "ext-session": "*",
      "ext-PDO": "*"
   }
}

Der tages derefter hensyn til disse regler, når der installeres pakker eller opgraderinger. Dette er med til at forhindre problemer, som ville blive synlige ved kørselstid. Typisk skal f.eks. en betalingsgatewaypakke kommunikere med API'et, så den skal indrømme afhængigheder af udvidelserne curl og json.

Fejlfinding af afhængigheder

Ofte opstår afhængighedskrænkelser på grund af en dårlig version af PHP. I dette tilfælde sender Composer en meddelelse, f.eks. "Din PHP-version (7.3.11), der er overstyret af "config.platform.php"-versionen (7.1), opfylder ikke dette krav.".

Meget ofte skyldes fejlen indstillingerne direkte i projektet composer.json, hvor følgende afsnit er:

"config": {
   "platform": {
      "php": "7.2"
   }
}

Ændringen skal foretages direkte i filen. I tilfælde af et globalt projekt (før installation eller med en global afhængighed) kan du fremtvinge Composer-versionen med composer config -g platform.php 7.2.14 (-g-switchen betyder global).

I nogle tilfælde ønsker vi at installere de nyeste pakkeversioner og ignorere de lokale miljøindstillinger. I dette tilfælde kan vi bruge den avancerede kommando:

$ composer update --ignore-platform-reqs

Brug switch'en ignore-platform-reqs på eget ansvar, den kan forårsage skade på projektet! Brug den ikke, hvis du ikke forstår konsekvenserne.

Manual Composer-opkald, parametre og hukommelsesstyring

Composer er faktisk et PHP-script pakket ind i en såkaldt PHAR, som er en kompileret version af et PHP-program. Det kan være nyttigt at kende disse oplysninger, f.eks. for at forbedre parametriseringen af selve opkaldet.

I virkelig store projekter sker det nogle gange, at vi løber tør for RAM og skal allokere meget mere eller øge behandlingstiden for scripts.

På Windows kan du f.eks. bruge denne kommando til det:

$ php -d memory_limit=-1 C:/xampp/htdocs/composer.phar update

Med memory_limit=-1 skifter Composer til ikke at være modtagelig over for RAM-grænsen og bruge så meget hukommelse, som den har brug for.

Brugerdefinerede brugermanuskripter efter Composer-handling

Når du har kørt Composer-handlinger, kan du påkalde automatisk udførelse af brugerdefinerede scripts, der enten udfører specifikke handlinger på projektet eller f.eks. genererer en konfiguration efter implementering. Jeg bruger primært denne fremgangsmåde på en lokal server for at tilbyde et automatisk database-konfigurationsværktøj, generere et databaseskema osv.

Vi registrerer de nødvendige scripts i afsnittet scripts i composer.json:

"scripts": {
   "post-autoload-dump": "Baraja\\PackageManager\\PackageRegistrator::composerPostAutoloadDump"
}

I dette tilfælde kaldes den statiske metode composerPostAutoloadDump i klassen Baraja\PackageManager\PackageRegistrator automatisk. Composer har denne klasse til rådighed, fordi den først genererede autoloader-klasserne.

Hvis vi blot ønsker at køre scripts og ikke udføre unødvendige handlinger med Composer, er kommandoen composer dump meget nyttig, da den blot genererer en ny autoloader (hvilket jeg anbefaler for altid at holde den opdateret) og derefter kører scripts med det samme. Hvis du vil prøve at bruge scripts, har jeg udarbejdet en færdig pakke [Baraja PackageManager] (https://github.com/baraja-core/package-manager), som implementerer smarte scripts og interaktiv grænseflade til Nette-rammen.

Versionering af Vendor i Git?

Et spørgsmål, som vi ofte diskuterer med udviklere, er, om indholdet af vendor-mappen skal versioneres i Git, eller om den skal genereres på ny ved hver installation.

Generelt synes den renere løsning at være at ikke versionere indholdet overhovedet og installere det hele hver gang. Men virkeligheden er, at en udvikler fra tid til anden stopper med at udvikle en pakke eller helt fjerner den. Den konstante downloading af pakker komplicerer også lokale installationer og opdateringer og gør også udrulninger langsommere og kan nogle gange forårsage korte nedbrud på webstedet, når nye pakkeversioner downloades forkert.

Jeg ser sælgerens suspension som en form for "sikkerhed". Hvis filerne er fysisk i versioneringssystemet, har vi i det mindste en rudimentær sikkerhed på produktionsserveren for, at pakkerne vil fungere, og at deres kode er nøjagtig som i den lokalt kørende installation. Desuden fylder Vendor ofte kun nogle få MB, hvilket bestemt er værd at sikre et fungerende websted i betragtning af de nuværende diskkapaciteter.

Praktisk note: For det gennemsnitlige websted, jeg vedligeholder, fylder vendor ikke mere end 30 MB, hvilket er en acceptabel kapacitet for Git. Når vi kloner et repository med junior, behøver vi ikke at træne ham i at få webstedet op og køre, og det virker bare "med det samme".

Brugerdefinerede Composer-pakker

Du kan oprette dine egne pakker i Composer, enten offentligt tilgængelige (registreret på Packagist) eller private (du skal have din egen pakkeserver, f.eks. Satis).

Spørgsmålet om oprettelse, vedligeholdelse, udvikling og versionering af pakker er meget komplekst og vil blive behandlet i en separat artikel.

I mellemtiden kan du læse artiklen [Semantic Versioning] (https://semver.org/lang/cs/), som jeg har oversat for dig.

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Kontakt