Composer - kompletní přehled funkcí pro pokročilé

Jak už víte, tak [Composer](https://getcomposer.org/) je robustní správce balíků a závislostí pro PHP, přes který můžete elegantně spravovat stovky projektů najednou a distribuovat již jednou napsaný kód do všech aplikací současně.

Tento návod slouží jako podrobná komplexní příručka vývojáře. Ukážeme si všechny důležité pokročilé techniky práce s Composerem, vysvětlíme si i technické detaily a relevantní návaznosti.

Instalace Composeru

Bez ohledu na platformu stáhneme z oficiálních stránek Composeru.

Interně se stáhne PHP soubor composer-setup.php, který po spuštění v CLI režimu umí Composer nainstalovat. Důležité je také vědět, že Composer bez PHP nefunguje, proto nejprve ověřte, že máte v počítači funkční PHP (stačí, aby bylo k dispozici jen pro Terminál).

Na Macu a Linuxu Composer funguje hned po instalaci a stačí zavolat příkaz composer -v, kterým rychle ověříte, že je Composer správně nainstalován.

V Linuxu lze pro instalaci použít příkaz: /usr/bin/php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');“

Na Windows je dobré doinstalovat nástroj Git Bash pro Windows, který umožňuje otevřít specifický Terminál, který se chová téměř jako Linux a umožní vám pracovat ve stejném prostředí, jako na Linuxu.

Instalace pro servery je stejná jako na lokálním prostředí. Jenom si ohlídejte správně nastavenou verzi PHP, kterou Composer interně používá.

Dostupné příkazy

Composer implementuje celou řadu příkazů.

Použití je: composer <příkaz>, například: composer update.

Přehled pro verzi 1.10.0:

Vytvoření projektu a jeho definice

Každý projekt spravovaný Composerem je definován souborem composer.json v jeho rootu, který definuje veškeré závislosti. Soubor můžeme vytvořit buď pro existující projekt ručně, nebo při zakládání projektu automaticky.

Protože v Composeru je všechno balík, tak i samotný projekt může být založen na základě balíku. Pokud tedy například vytváříte desítky nebo stovky velmi podobných projektů, dává smysl jejich základní konfiguraci a strukturu umístit do samostatného balíku, na základě kterého je možné provést instalaci.

Příkladem takového balíku je můj Baraja Sandbox, který je postaven na čistém Nette 3.0 a přidává základní závislost na můj Package Manager, který používám pro všechny projekty a správu závislostí v Nette konfiguraci.

Sandbox pak nainstalujeme jednoduše příkazem:

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

Podle názvu projektu poté Composer automaticky vytvoří složku, do které projekt nainstaluje (zkopíruje obsah balíku a nainstaluje závislosti).

Ve složce vendor poté Composer spravuje všechny balíky (jsou tam jejich fyzické soubory) a generuje autoload tříd, který vložíme ideálně přímo do index.php jako řádek:

<?php

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

// Samotný kód aplikace

Instalace dalších balíků a závislostí

V rámci funkčního projektu můžeme velmi jednoduše instalovat nové balíky a přidávat závislosti.

Dělá se to 2 způsoby:

• Příkazem composer require ...,
• Přidáním závislosti přímo do souboru composer.json do sekce require a poté příkaz composer update.

Zkuste si nainstalovat například PackageManager: composer require baraja-core/package-manager, nebo Doctrine: composer require baraja-core/doctrine.

Pokud zvolený balík nelze nainstalovat, lze se zeptat na konkrétní důvody a Composer vypíše seznam závislostí, které tomu brání. Často stačí opravit závislost na konkrétní verzi nebo odebrat nekompatibilní kód. Podrobné informace získáme příkazem: composer why baraja-core/doctrine.

Aktualizace projektů a balíků

Dobře navržený projekt se vyvíjí tak, aby šlo v čase jednoduše stahovat aktualizace a měli jste vždy k dispozici nejnovější verze všech balíků. Hlavní benefit je zejména v tom, že získáte opravu všech chyb, často vylepšení výkonu a spoustu nových funkcí. Navíc díky postupnému přecházení nebude update po dlouhé době tak komplikovaný, protože budete řešit problémy za chodu v menším měřítku a vyhnete se nekompatibilitám.

Všechny balíky a závislosti aktualizujete příkazem: composer update.

Samotný update proces může v některých případech selhat. Důvodem obvykle bývá buď porušená závislost nebo nekompatibilní balík.

Podrobné informace, proč balík nelze nainstalovat získáme příkazem: composer why-not baraja-core/doctrine. Pokud balík už máme a nefunguje jen jeho konkrétní verze (nechce se nainstalovat), můžeme se zeptat i na konkrétní verzi: composer why-not baraja-core/doctrine:v1.0.20.

V rámci souboru composer.json můžeme také uvést závislost na konkrétní běhové prostředí. To se hodí zejména v případě, kdy projekt vyvíjíme s více lidmi a chceme ověřit, že mají nainstalovány všechna rozšíření.

Typicky se kontroluje verze PHP (musí být verze 7.1.0 nebo novější):

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

Případně i další systémová rozšíření:

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

Při instalaci balíků nebo aktualizaci se poté zohledňují i tato pravidla. Pomáhá to předcházet problémům, které by se projevily až za běhu. Typicky například balík pro platební bránu potřebuje komunikovat s API, proto musí přiznávat závislost na rozšíření curl a json.

Řešení potíží se závislostmi

Často dochází k porušení závislostí z důvodu špatné verze PHP. Composer v takovém případě vyhodí hlášku například your PHP version (7.3.11) overridden by "config.platform.php" version (7.1) does not satisfy that requirement..

Velmi často za chybu může nastavení přímo v projektovém composer.json, kde je následující sekce:

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

Změnu musíte provést přímo v souboru. V případě globálního projektu (ještě před instalací nebo při globální závislosti) lze verzi Composeru vnutit příkazem: composer config -g platform.php 7.2.14 (přepínač -g znamená global).

V některých případech chceme nainstalovat nejnovější verze balíků a ignorovat nastavení lokálního prostředí. V takovém případě lze použít pokročilý příkaz:

$ composer update --ignore-platform-reqs

Přepínač ignore-platform-reqs používejte na vlastní nebezpečí, může způsobit poškození projektu! Nepoužívejte, pokud nechápete důsledky.

Ruční volání Composeru, parametry a správa paměti

Composer je ve skutečnosti PHP script zabalený do tzv. PHARu, což je zkompilovaná verze PHP aplikace. Když tuto informaci víme, tak toho lze dobře využít například pro lepší parametrizaci samotného volání.

Při opravdu velkých projektech se totiž občas stane, že dojde operační paměť a je potřeba přidělit mnohem víc, případně prodloužit čas zpracování scriptů.

Například na Windows pro to lze použít tento příkaz:

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

Přičemž přepínač memory_limit=-1 říká, aby nebyl Composer náchylný na limit operační paměti a spotřeboval libovolně kolik potřebuje.

Vlastní uživatelské scripty po Composer akci

Po spuštění Composer akcí lze vyvolat automatické spuštění uživatelsky definovaných scriptů, které buď provedou specifické akce nad projektem, nebo například vygenerují konfiguraci po deployi. Tento přístup používám zejména na lokálním serveru pro nabídnutí automatického nástroje pro konfiguraci databáze, vygenerování databázového schématu a podobně.

Požadované scripty zaregistrujeme do sekce scripts v composer.json:

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

V tomto případě se provede automatické zavolání statické metody composerPostAutoloadDump v třídě Baraja\PackageManager\PackageRegistrator. Composer má tuto třídu k dispozici, protože nejprve provedl generování autoloaderu tříd.

Pokud chceme spustit jen scripty a neprovádět zbytečné akce s Composerem, tak velmi dobře poslouží příkaz composer dump, který pouze vygeneruje nový autoloader (což doporučuji, aby byl vždy aktuální) a poté ihned spustí scripty. Pokud si chcete použití scriptů vyzkoušet, připravil jsem hotový balík Baraja PackageManager, který chytré scripty a interaktivní rozhraní implementuje pro Nette framework.

Verzovat Vendor do Gitu?

S vývojáři často řešíme otázku, jestli verzovat obsah složky vendor do Gitu, nebo ji nechat vygenerovat na každé instalaci znovu.

Obecně se jako čistější řešení jeví obsah vůbec neverzovat a pokaždé vše nainstalovat. Realita je ale taková, že čas od času vývojář přestane balík vyvíjet, nebo ho úplně odstraní. Neustálé stahování balíků navíc komplikuje lokální instalace a aktualizace a také zpomaluje deploye a občas může za krátké výpadky webu, když se špatně stáhnou nové verze balíků.

Zaverzování Vendoru vnímám jako určitou formu "jistoty". Pokud jsou soubory fyzicky ve verzovacím systému, tak máme na produkčním serveru aspoň elementární jistotu, že budou balíky fungovat a jejich kód je přesně takový, jako je v lokálně běžící instalaci. Navíc Vendor často zabírá jen jednotky MB, což za jistotu funkčního webu vzhledem ke kapacitám dnešních disků určitě stojí.

Praktická poznámka: U průměrného webu, který spravuji, zabírá vendor maximálně 30 MB, což je pro Git akceptovatelná kapacita. Při klonování repositáře juniorem pak nemusíme řešit jeho zaškolování, jak web zprovoznit a zkrátka "hned funguje".

Vlastní Composer balíky

V rámci Composeru můžete vytvářet vlastní balíky, a to buď veřejně dostupné (registrují se na Packagist), nebo privátní (musíte mít vlastní balíkový server, například Satis).

Problematika zakládání, správy, vývoje a verzování balíků je velmi komplexní a vznikne pro to samostný článek.

V mezičase si můžete přečíst článek Sémantické verzování, který jsem pro vás přeložil.

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:

KontaktSpolupráce