Bättre WordPress-kod: Composer Lock-filen
Innan vi avslutar vår diskussion om Composer har vi en viktig sak kvar att diskutera: leverantörskatalogen (och i förlängningen Composer-låsfilen).
Specifikt måste vi prata om varför vi inte behöver överlåta leverantörskatalogen till förvaret utan hur våra bidragsgivare kan vara säkra på att de har den senaste versionen av programvaran som behövs för att fungera med vår kodbas.
Att använda kodkvalitetsverktyg för att skriva bättre WordPress-kod är viktigt, ja, men att förstå hur man korrekt hanterar beroenden och vårt arkiv är också viktigt. Så innan vi tittar på nämnda verktyg, låt oss granska låsfilen, vilken roll den spelar och varför vi inte behöver överföra leverantörskatalogen till vårt arkiv.
Bättre WordPress-kod med Composer Lock-filen
För de som arbetar med WordPress – och kanske i andra PHP-baserade ramverk och grunder (jag vet inte riktigt eftersom jag tenderar att inte arbeta med dem) – finns det ett beroende av Composer, vilket är bra.
Detta kan också leda till att man vill begå hela leverantörskatalogens källkontroll, vilket inte är bra.
Som nämndes i förra inlägget :
Och jag rekommenderar inte att du kontrollerar leverantörskatalogen i ditt förråd. Det kan bli en enorm katalog senare, och det kan undergräva hela syftet med Composer.
Så hur kan vi se till att vi inte överför filer i onödan (och därmed ökar storleken på vårt arkiv) till arkivet samtidigt som vi ser till att våra bidragsgivare använder samma version av programvaran som vi?
Önskan att begå leverantörskatalogen
För de av er som har kört Composer och är bekanta med att åtminstone se leverantörskatalogen, då är du sannolikt van vid att se flera kataloger med beroenden som är installerade.
Och de är användbara; annars hade du inte tagit med dem, eller hur?
Men här är grejen med leverantörskatalogen : även om du bara har några få beroenden installerade med ditt projekt, kan själva filstorleken vara stor. Och detta kan bli ännu större när du har många beroenden.
Oavsett vilket verkar det vara vettigt att begå detta till källkontroll, eller hur? Vi vill se till att alla har samma version av programvaran som vi använder och vi vill se till att de inte behöver hantera Composer.
Det finns dock ett annat sätt. Och det håller vårt förråd litet samtidigt som det ser till att versionerna av våra beroenden hålls synkroniserade med de som klona förvaret, förbinder sig till förvaret eller för något kontinuerligt integrationsverktyg som använder förvaret.
Förstå låsfilen
Innan jag pratar om leverantörskatalogen vill jag beröra en annan viktig aspekt av Composer: låsfilen. Det vill säga, om du kör installations- eller uppdateringskommandot i din terminal, kommer du att se en låsfil genererad tillsammans med leverantörskatalogen.
Vad är denna fil?
Det föregående inlägget visade ett exempel på en konfigurationsfil. En av de saker som den här filen också tillåter oss att göra är att definiera tredjepartsbibliotek, eller beroenden, som vi kan använda i våra projekt.
Jag har pratat om detta i andra inlägg (och vi kan titta på detta lite mer senare i den här serien). Men det är här låsfilen kommer in i bilden.
Kort sagt, låsfilen innehåller alltid information om versionen – den exakta versionen – av de beroenden som används med projektet senaste gången installationen eller uppdateringen kördes.
När Composer har installerat klart, skriver den alla paket och de exakta versionerna av dem som den laddade ner till filen composer.lock, vilket låser projektet till de specifika versionerna.
Du bör överföra filen composer.lock till din projektrepo så att alla personer som arbetar med projektet är låsta till samma versioner av beroenden (mer nedan).
Målet är att se till att alla kör samma version av projektets beroenden – inte äldre versioner, inte nyare versioner – utan samma version.
Så när du kör composer installera när en låsfil ingår i förvaret kommer att använda den version av programvaran som definieras i låsfilen.
Och detta säkerställer att alla kör samma version av varje beroende och därmed kan förhindra behovet av att överlåta leverantörskatalogen till källkontroll.
Skriver kod för högre kvalitet
Så vart går vi härifrån?
Nu när vi förstår hur man använder Composer och hur man använder låsfilen, kan vi börja prata om faktiska beroenden som hjälper till att förbättra vår kodkvalitet.
Och när vi pratar om att skriva kod av högre kvalitet finns det verktyg som är gjorda just för det. Så i de kommande inläggen ska vi titta på några av dem.