Parem WordPressi kood: helilooja lukustusfail
Enne Composeri teemalise arutelu lõpetamist on meil veel üks oluline asi arutada: tarnija kataloog (ja laiemalt ka Composeri lukufail).
Täpsemalt peame rääkima sellest, miks me ei pea hankija kataloogi hoidlasse siduma, vaid sellest, kuidas meie kaastöötajad saavad olla kindlad, et neil on meie koodibaasiga töötamiseks vajaliku tarkvara uusim versioon.
Koodikvaliteedi tööriistade kasutamine parema WordPressi koodi kirjutamiseks on oluline, jah, kuid oluline on ka arusaamine, kuidas sõltuvusi ja meie hoidlat õigesti hallata. Nii et enne nimetatud utiliitide vaatamist vaatame üle lukufaili, selle rolli ja selle, miks me ei pea hankija kataloogi oma hoidlasse siduma.
Parem WordPressi kood helilooja lukustusfailiga
Need, kes töötavad WordPressiga – ja võib-olla ka muudes PHP-põhistes raamistikes ja sihtasutustes (ma tegelikult ei tea, sest ma ei kipu nendega töötama) – toetuvad Composerile, mis on hea.
See võib põhjustada ka soovi kasutada kogu tarnija kataloogi allika juhtimist, mis pole hea.
Nagu eelmises postituses mainitud :
Ja ma ei soovita hankija kataloogi oma hoidlasse kontrollida. Sellest võib hiljem saada tohutu kataloog ja see võib kahjustada kogu Composeri eesmärki.
Niisiis, kuidas saame tagada, et me ei lisa faile asjatult (ja seega ei suurenda hoidla suurust) hoidlasse, tagades samal ajal, et meie kaasautorid kasutavad sama tarkvara versiooni, mis meie?
Soov siduda hankijate kataloog
Need, kes on Composerit käivitanud ja tunnevad vähemalt tarnija kataloogi nägemist, olete tõenäoliselt harjunud nägema mitut installitud sõltuvuste kataloogi.
Ja need on kasulikud; muidu te poleks neid kaasanud, eks?
Kuid siin on asi tarnija kataloogi kohta: isegi kui teie projektiga on installitud vaid mõned sõltuvused, võib faili suurus olla suur. Ja see võib olla veelgi suurem, kui teil on palju sõltuvusi.
Sellele vaatamata näib selle allika kontrollile omistamine olevat mõistlik, eks? Tahame tagada, et kõigil oleks sama tarkvara versioon, mida me kasutame, ja tahame tagada, et nad ei peaks Composeriga tegelema.
Siiski on ka teine viis. Ja see hoiab meie hoidla väikesena, tagades ühtlasi, et meie sõltuvuste versioonid hoitakse sünkroonis nendega, kes hoidla kloonivad, hoidlale pühenduvad või mis tahes hoidlat kasutava pideva integreerimise utiliidi jaoks.
Lukustusfaili mõistmine
Enne tarnija kataloogist rääkimist tahan puudutada veel üht olulist Composeri aspekti: lukufaili. See tähendab, et kui käivitate oma terminalis installi- või värskendamiskäskluse, näete koos tarnija kataloogiga genereeritud lukufaili.
Mis see fail on?
Eelmine postitus näitas konfiguratsioonifaili näidet. Üks asi, mida see fail võimaldab meil teha, on määratleda kolmanda osapoole teegid või sõltuvused, mida saame oma projektides kasutada.
Olen sellest rääkinud teistes postitustes (ja me saame seda selles sarjas hiljem veidi lähemalt vaadata). Kuid siin tuleb mängu lukufail.
Lühidalt öeldes sisaldab lukufail alati teavet nende sõltuvuste versiooni – täpse versiooni – kohta, mida viimase installi või värskenduse käivitamisel projektiga kasutati.
Kui Composer on installimise lõpetanud, kirjutab ta kõik allalaaditud paketid ja nende täpsed versioonid faili composer.lock, lukustades projekti nendele konkreetsetele versioonidele.
Peaksite faili composer.lock oma projekti reposse siduma, et kõik projektiga töötavad inimesed oleksid lukustatud samadele sõltuvuste versioonidele (lisateave allpool).
Eesmärk on tagada, et kõigil oleks sama versioon projekti sõltuvustest – mitte vanemaid ega uuemaid versioone, vaid sama versioon.
Nii et kui käivitate helilooja installi, kui hoidlasse on lisatud lukustusfail, kasutab see tarkvara versiooni, mis on määratletud lukufailis.
Ja see tagab, et kõik kasutavad iga sõltuvuse sama versiooni ja seega saab vältida vajadust siduda hankija kataloog allika juhtimisega.
Kõrgema kvaliteedikoodi kirjutamine
Kuhu me siis läheme?
Nüüd, kui me mõistame, kuidas kasutada Composerit ja kuidas lukufaili kasutada, võime hakata rääkima tegelikest sõltuvustest, mis aitavad parandada meie koodi kvaliteeti.
Ja kui me räägime kvaliteetsema koodi kirjutamisest, siis on olemas just selle jaoks loodud utiliidid. Nii et järgmistes postitustes vaatleme mõnda neist.