Slovník pojmů

Composer

Composer popisuje, instaluje a opakovatelně skládá PHP závislosti. Nejde jen o stažení knihoven: rozhoduje také o verzích, autoloadingu a bezpečném nasazení stejného kódu.

Stručná definice

Závislosti jsou součást zdrojového kódu, i když neleží ve vlastním repozitáři.

Composer je nástroj, kterým PHP projekt deklaruje knihovny, rozšíření a podporované verze PHP. Soubor composer.json říká, co aplikace potřebuje; Composer potom vyřeší také nepřímé závislosti jednotlivých balíčků. Výsledné balíčky ukládá do adresáře vendor a zpřístupní je přes vygenerovaný soubor vendor/autoload.php.

V aplikaci je stejně důležitý composer.lock. Zachycuje konkrétní rozhodnutí závislostního resolveru včetně přesných verzí a referencí zdrojů balíčků. Díky tomu může vývojář, CI i produkční server nainstalovat stejnou ověřenou sadu, místo aby při každém nasazení znovu hledali nejnovější verze vyhovující jen přibližnému omezení.

K čemu se používá

Od frameworku po nástroje pro kvalitu kódu

V typickém PHP projektu Composer spojuje běhové knihovny, vývojové nástroje i pravidla, jak se načítá vlastní kód.

instalace frameworku, databázových knihoven a klientů externích API
oddělení produkčních závislostí od nástrojů používaných jen při vývoji a v CI
PSR-4 autoloading vlastního kódu z adresářů jako src nebo tests
spouštění sjednocených kontrol a pomocných příkazů přes Composer scripts
opakovatelné sestavení stejného PHP prostředí pro lokální vývoj, test a nasazení

Praktický příklad

Importer má jasně popsané knihovny i vlastní namespace

Následující ukázka používá záměrně fiktivní klient pro dopravce. Důležitý je princip: běhová závislost patří do require, testovací nástroj do require-dev a vlastní třídy mají určené, odkud se automaticky načítají. Po změně deklarace se v aplikaci provede řízený update a výsledný composer.lock se zkontroluje v pull requestu.

Na produkci se pak nepouští obecný update. Nasazení instaluje přesně verze zachycené v lock souboru; tím se sníží rozdíl mezi prostředím, ve kterém prošly testy, a prostředím, ve kterém běží import objednávek.

{
  "require": {
    "acme/shipping-client": "^2.4"
  },
  "require-dev": {
    "phpunit/phpunit": "^11.0"
  },
  "autoload": {
    "psr-4": { "App\\": "src/" }
  }
}

Jak funguje

Od deklarace po stejný build v každém prostředí

Composer nejprve hledá kompatibilní graf balíčků a potom jej zafixuje pro další instalace.

Deklarace composer.json popíše požadované balíčky, verze PHP, vlastní autoloading a případné skripty projektu.
Vyřešení verzí Příkaz update vybere verze, které odpovídají omezením projektu i jejich vzájemným závislostem.
Lock soubor composer.lock zapíše konkrétní rozhodnutí. U nasazované aplikace patří do verzovacího systému.
Instalace Příkaz install podle lock souboru stáhne přesně vybrané balíčky do vendor, bez nového hledání verzí.
Autoloading Vygenerovaný autoloader propojí třídy balíčků i vlastní PSR-4 namespace; aplikace jej načte na vstupu.

Hlavní části a pojmy

Deklarace, zámek a autoloader mají rozdílnou roli.

Dobrá práce s Composerem nespočívá v tom, že existuje adresář vendor, ale v porozumění tomu, jak vznikl.

composer.json

Je záměr projektu: uvádí přímé závislosti, verzi PHP, autoloading, repozitáře a skripty. Verze jsou omezení, ne záznam přesného stavu prostředí.

composer.lock

Je konkrétní výsledek řešení verzí. V aplikaci se commitne a při instalaci určuje přesnou sadu balíčků; ruční úpravy locku jsou rizikové.

install a update

install nainstaluje uzamčený stav. update znovu řeší vybrané či všechny závislosti a může změnit lock soubor; proto vyžaduje review a testy.

Autoloading

PSR-4 mapuje namespace na adresáře a brání ručnímu require každé třídy. Composer umí i classmap či soubory, ale příliš mnoho automaticky načítaného kódu zhoršuje přehled.

Scripts, pluginy a audit

Skripty sjednotí příkazy týmu, ale při instalaci mohou spouštět kód. Změny balíčků, pluginů a bezpečnostní upozornění proto patří do běžného review, ne mimo něj.

Vztah k ostatním nástrojům

Správa balíčků není ani framework, ani deployment sama o sobě.

Composer vytváří předpoklad pro další nástroje; nevynucuje však architekturu ani kvalitu aplikace.

Packagist a repozitáře: Jsou katalogem a zdrojem balíčků. Dostupnost balíčku ještě neznamená, že jeho licence, údržba a bezpečnost odpovídají projektu.
PHP extensions a platforma: Požadavky mohou zahrnout verzi PHP i rozšíření. Stejné composer.json nenahradí kontrolu skutečné verze PHP, systémových knihoven a konfigurace serveru.
Framework: Symfony, Laravel nebo Nette dávají aplikační konvence. Composer pouze nainstaluje framework a jeho závislosti, neurčí hranice businessové logiky.
CI a deployment: Pipeline ověří, že se lock soubor dá nainstalovat, a spustí kontroly. Samotný úspěšný install neověří funkčnost integrace ani bezpečnost změny databáze.

Výhody a omezení

Opakovatelnost má cenu pravidelné údržby závislostí.

Přínosy

stejná sada knihoven v lokálním prostředí, CI a nasazení
standardizovaný PSR-4 autoloading vlastního i cizího kódu
oddělení běhových a vývojových nástrojů
řízené aktualizace s dohledatelnou změnou v lock souboru

Rizika a chyby

spuštění širokého update bez review může přinést mnoho nesouvisejících změn
necommitnutý lock soubor vede u aplikace k jiným verzím v různých prostředích
ruční úpravy vendor se při další instalaci ztratí
přidávání balíčků jen kvůli malé utilitě zvyšuje supply-chain i provozní povrch

Kdy dává smysl

Většina udržovaných PHP aplikací potřebuje řízené závislosti.

Composer je přiměřený už ve chvíli, kdy projekt používá framework, klienta API, testovací nástroj nebo chce držet vlastní třídy v předvídatelném namespace. U dlouhodobého e-shopu či API je lock soubor jedním z praktických podkladů pro reprodukovatelné nasazení a řešení incidentů.

Není nutné přidávat závislost pro každý řádek pomocného kódu. U malé lokální funkce může být čitelnější ji napsat a otestovat přímo. Rozhodnutí závisí na údržbě, licenci, bezpečnostních aktualizacích, kompatibilitě a tom, zda balíček skutečně řeší významný problém lépe než vlastní jednoduchý kód.

Praktická pravidla

Závislosti aktualizovat záměrně, ne náhodou.

Změna composer.json nebo composer.lock je změna kódu projektu a zaslouží si stejnou pozornost jako jiná změna.

commitnout composer.json i composer.lock u nasazované aplikace
před produkčním nasazením používat install nad ověřeným lock souborem, ne obecný update
při aktualizaci procházet changelog, rozdíl locku, licence a aktivitu údržby balíčku
držet vlastní PSR-4 namespace jednoduché a bez kolidujících classmap pravidel
spouštět testy, statickou analýzu a bezpečnostní kontrolu po změně závislostí

Časté otázky

Co znamenají běžné příkazy a soubory Composeru

Jaký je rozdíl mezi composer install a composer update?

install používá verze z composer.lock. update znovu hledá verze podle omezení v composer.json a lock může změnit. Na nasazení aplikace je obvykle správný první případ, aktualizace patří do řízené změny s testy.

Má být composer.lock ve verzovacím systému?

U aplikace ano: popisuje konkrétní sestavení, které lze opakovat. U knihovny se rozhodnutí liší, protože její uživatelé musí své závislosti vyřešit ve vlastním projektu.

Patří adresář vendor do Gitu?

Obvykle ne. Je odvoditelný z Composer souborů a instalace. Výjimky mohou existovat v omezeném distribučním prostředí, ale je potřeba je vědomě spravovat.

Vyřeší Composer bezpečnost sám?

Ne. Umí pomoci s přehledem známých problémů, ale bezpečný proces stále potřebuje aktualizace, posouzení změn, testy a důvěru v používané zdroje.

Jak pracuji s PHP v praxi

Závislosti beru jako součást udržovatelného backendu.

U PHP aplikací propojuji frameworky, integrační knihovny a quality gates tak, aby šlo změny bezpečně sestavit, otestovat a nasadit.

Jak používám PHP v praxi Nezávazně probrat projekt