Kahdeksan Composerin komentoa, jotka jokaisen PHP-kehittäjän tulisi tuntea

Artikkelin Näin aloitat Composerin käytön jatkona esittelen joitakin yleisimpiä komentoja, jotka jokaisen PHP-kehittäjän tulisi tuntea. Näitä komentoja tarvitaan usein päivittäisessä työssä. Joka on käyttänyt aiemmin jotakin paketinhallintaohjelmaa, kuten npm tai yarn, löytää tästä monia samankaltaisuuksia.

Install eli riippuvuuksien lataus ja konfigurointi.

composer install -komento suoritetaan asentamaan riippuvuuksien tarkat versiot, jotka on kuvailtu composer.lock-tiedostossa. Tämä on alustava komento, kun ladataan versionhallinnasta uusi koodi ja vendor-hakemisto (paikka, johon asennetaan paketit) on tyhjä. Jos composer.lock-tiedostoa ei ole, asennetaan mahdollisimman uudet versiot, kuten update-komennollakin.

Update eli riippuvuuksien päivittäminen.

composer update tarkastaa composer.json-tiedoston sisällön, johon on merkitty halutut riippuvuudet, ja asentaa sen mukaan uusimmat paketit. Sitten tarkastetaan kaikki paketit, jotta asennettavat versiot ovat yhteensopivia toisiinsa. Se päivittää myös composer.lock-tiedoston tallentamalla siihen asennetun tilanteen, jotta seuraavalla install-komennolla käytetään jo vastaavia versioita.

Require eli uuden riippuvuuden asentaminen

composer require vendor/paketinnimi käytetään uuden riippuvuuden asentamiseen. Jos vastaava paketti löytyy, tarkastetaan sen riippuvuudet muista asennetuista paketeista ja ladataan koneelle uusin versio. Lisäksi se merkitään composer.json-tiedostoon ja päivitetään tarkalla asennetulla versiolla myös composer.lock-tiedosto.

Remove eli riippuvuuden poistaminen.

composer remove vendor/paketinnimi poistaa riippuvuuden tiedostot ja sen tiedon sekä composer.json– että composer.lock-tiedostosta, jotta tätä riippuvuutta ei asenneta myös seuraavalla composer install-komennolla.

Outdated eli päivitysten tarkastus

composer outdated antaa tietoa paketeista, joista on saatavilla uudempi versio. Tarkastetaan, että uudemmat versiot sopivat composer.json-tiedostossa määriteltyihin riippuvuuksiin. Erikseen merkitään suorat riippuvuudet, jotka on lueteltu composer.json-tiedostossa, ja myös sellaiset riippuvuudet, jotka ovat tulleet muiden pakettien mukana.

Audit eli haavoittuvuuksien tarkastus

composer audit tarkastaa pakettien haavoittuvuudet Packagist.org API-palvelun kautta. Jos jotkin CVE-koodit tosiasiallisesti eivät vaikuta sovelluksen yhteydessä heikkouksilta, ne voidaan määrätä composer.json-tiedostossa sivuutettaviksi. Audit ilmoittaa myös hylätyistä paketeista, joita ei enää kehitetä, mikä tarkoittaa, että vastaava riippuvuus tulisi korvata jollakin uudella.

Depends näyttää, miksi vastaava paketti on asennettu.

composer depends vendor/paketinnimi näyttää, miksi jokin riippuvuus on asennettu. Tästä on hyötyä, jos jokin paketti joutuu riippuvuudessa ristiriitaan jonkin muun paketin kanssa, joka halutaan asentaa, tai jos tarkastus ilmoittaa jostakin haavoittuvuudesta. Tämä on erittäin tärkeää, jos kyseinen riippuvuus ei ole määritelty composer.json-tiedostossa, vaan on tullut jonkin kolmannen osapuolen paketin mukana. Tämä auttaa tekemään päätöksen jatkotoimista. Esimerkiksi kolmannen osapuolen paketin päivittäminen voi auttaa, jos uudemmassa versiossa ei ole kyseistä riippuvuutta, tai jopa suoran riippuvuuden korvaaminen jollakin muulla paketilla.

Show näyttää riippuvuuden tiedot.

composer show vendor/paketinnimi näyttää asennetun riippuvuuden tarkemmat tiedot, muun muassa tarkan asennetun version ja sen riippuvuudet.

Lopuksi

Yhteenvetona voidaan todeta, että Composer on tehokas työkalu, jolla on helppo hallita ja asentaa riippuvuuksia, pitää projektit ajan tasalla ja varmistaa, että kaikki tarvittavat paketit toimivat saumattomasti yhdessä. Edellä kuvaillut komennot, kuten install, update, require ja remove, ovat välttämättömiä päivittäiseen työhön. Samalla sellaiset komennot, kuten outdated, audit, depends ja show, auttavat kehittäjiä seuraamaan ja hallinnoimaan projektien riippuvuuksia toisellakin tasolla.

Tässä artikkelissa yritin järjestää komennot niiden käyttötiheyden mukaan, mikä on tietysti hyvin subjektiivista eli projekti- ja kehittäjäkohtaista.