# Composer: správce balíčků pro PHP

> Composer vysvětlen: pochopte composer.json, composer.lock, vendor a autoloader, čistě nasazujte do produkce a bezpečně udržujte závislosti.

Zdroj: https://phpsos.de/cs/php/composer/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** Composer je správce balíčků pro PHP. Ze souboru `composer.json` načte, jaké knihovny projekt potřebuje, stáhne je do adresáře `vendor`, přesné verze zaznamená v `composer.lock` a vytvoří autoloader, který třídy automaticky najde. Composer tak spravuje kód vaší aplikace, nikoli samotný interpret PHP: aktualizace Composeru neuzavře zranitelnost v PHP, jako je PHP2Shell.

## Co je Composer a k čemu slouží?

Dnes už téměř žádná aplikace PHP nestojí jen na vlastním kódu. Frameworky, knihovny pro e-maily, tvorba PDF nebo napojení plateb přicházejí jako hotové balíčky. Composer, správce balíčků pro PHP, zajišťuje, aby se tyto balíčky sešly ve vhodných verzích a aby každá závislost přinesla své vlastní závislosti.

Pro rozhodovatele to znamená: velká část kódu, který na vašem serveru běží, pochází od třetích stran. To je efektivní, ale vyžaduje to péči. Pro správce a vývojáře to znamená: kdo Composer používá čistě, může kdykoli dohledat, jaká verze které knihovny běží v produkci.

Standardním zdrojem balíčků je podle dokumentace Composeru Packagist.org. Další zdroje, například interní repozitáře agentury, lze zapsat do `composer.json` pod `repositories`.

## composer.json, composer.lock a vendor: tři stavební kameny

Composer pracuje se třemi věcmi, které je dobré znát, než převezmete server nebo zadáte práci agentuře.

| Stavební kámen | Obsah | Patří do repozitáře? |
|---|---|---|
| `composer.json` | požadované balíčky s rozsahy verzí (`require`, `require-dev`), pravidla autoload, nastavení | ano |
| `composer.lock` | přesně vyřešené verze všech balíčků, i nepřímých | ano, podle dokumentace Composeru výslovně |
| `vendor/` | stažený kód balíčků a vytvořený autoloader | ne, vytváří se při instalaci |

Pod `require` jsou balíčky, které aplikace potřebuje v provozu. Pod `require-dev` jsou nástroje pro vývoj a testy, například testovací frameworky nebo statická analýza. Toto rozdělení je důležité, protože vývojové nástroje na produkčním serveru nemají co dělat.

```json
{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}
```

Údaje o verzích v příkladu jsou zvoleny jen pro ilustraci. Které verze váš projekt potřebuje, vyplývá z jeho požadavků.

## install nebo update: rozdíl v provozu

Oba příkazy znějí podobně, ale mají velmi odlišné důsledky.

- `composer install` čte `composer.lock` a nainstaluje přesně tam zaznamenané verze. Je to reprodukovatelné a patří to do nasazení.
- `composer update` znovu vyřeší všechny závislosti, stáhne nejnovější odpovídající verze a přepíše `composer.lock`. To patří do vývoje, s následnými testy.

Podle dokumentace Composeru provede `update` po zápisu souboru lock navíc bezpečnostní kontrolu (audit), pokud se nevypne pomocí `--no-audit`. `install` standardně nekontroluje; k tomu slouží volba `--audit`.

## Autoloading: jak Composer najde třídy

Composer vytváří soubor `vendor/autoload.php`. Jakmile se jednou vloží, PHP načte každou třídu teprve ve chvíli, kdy je potřeba. Pro vlastní kód se v sekci `autoload` stanoví, který jmenný prostor leží v kterém adresáři. Doporučuje se k tomu PSR-4, standard skupiny PHP-FIG. Jak přesně to funguje, vysvětluje stránka [Jmenné prostory a autoloading](https://phpsos.de/cs/php/namespaces-autoloading/); přehled všech standardů poskytuje stránka [Standardy PSR](https://phpsos.de/cs/php/psr-standards/).

```php
<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // načte se automaticky podle potřeby
```

## Composer v produkci: čisté nasazení

Pro nasazení se osvědčilo pevné pořadí. Nejlépe probíhá v build pipeline a ne ručně na serveru.

1. **Zkontrolovat soubor lock:** `composer validate` zajistí, že `composer.json` je platný a `composer.lock` aktuální.
2. **Instalovat bez vývojových balíčků:** `composer install --no-dev` vynechá `require-dev`.
3. **Optimalizovat autoloader:** `--optimize-autoloader` (zkráceně `-o`) převede pravidla na seznam tříd. S `--classmap-authoritative` načítá PHP třídy výhradně z tohoto seznamu.
4. **Bezpečnostní kontrola:** `composer audit --locked` ověří verze ze souboru lock proti známým bezpečnostním hlášením a hlásí opuštěné balíčky.
5. **vendor mimo webroot:** Přes URL by měl být dostupný jen veřejný adresář se vstupním skriptem.

```bash
composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev
```

`composer outdated` navíc ukazuje, které nainstalované balíčky mají novější verze. To je základ pro plánované aktualizace místo hektických jednotlivých akcí.

## Composer, bezpečnost a PHP2Shell

Composer a PHP2Shell se týkají dvou různých úrovní. Zranitelnosti CVE-2026-109618 a CVE-2026-109619 leží v samotném interpretu PHP. Opraveny jsou v PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35 a poté je nutné restartovat všechny procesy PHP. Žádné `composer update` ani balíček ve `vendor` na tom nic nezmění.

Přesto patří Composer do každé kontroly po incidentu. Kdo dostane na server škodlivý kód, může měnit i soubory ve `vendor`, a `vendor/autoload.php` se načítá při každém požadavku. Čerstvé `composer install` z ověřeného souboru lock do prázdného adresáře je proto dobrý způsob, jak obnovit stav balíčků. Jak závislosti pravidelně kontrolovat na známé zranitelnosti, popisuje průvodce [composer audit](https://phpsos.de/cs/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Důležité:**
> Zelený výsledek `composer audit` nic neříká o stavu záplat PHP. Běhové prostředí PHP kontrolujte zvlášť, například pomocí naší [služby PHP-Patch](https://phpsos.de/cs/leistungen/php-patch-service/).

## Jak konkrétně pomáhá PHP SOS?

- Pro každou aplikaci zjistíme verzi PHP, balíčky Composeru a stav souboru lock a přitom čistě oddělíme interpret od knihoven.
- Ověříme, zda `vendor` a soubor lock k sobě sedí a zda v produkci neleží vývojové balíčky nebo změněné soubory.
- Zřídíme reprodukovatelné nasazení s `install --no-dev`, optimalizovaným autoloaderem a auditem.
- Po incidentu obnovíme stav balíčků z ověřeného souboru lock a zdokumentujeme výsledek.


## Časté dotazy

**Musí být composer.lock v repozitáři Git?**  
Ano. Dokumentace Composeru výslovně doporučuje composer.lock commitovat. Jen tak instalují vývoj, CI a produkce přesně stejné verze balíčků.

**Jaký je rozdíl mezi composer install a composer update?**  
install nainstaluje verze zaznamenané v composer.lock. update znovu vyřeší závislosti, stáhne odpovídající novější verze a přepíše composer.lock. Na produkční server patří jen install.

**Uzavře aktualizace Composeru zranitelnost PHP2Shell?**  
Ne. Composer spravuje knihovny vaší aplikace, nikoli interpret PHP. PHP2Shell se uzavře jen aktualizací běhového prostředí PHP na opravenou verzi a restartem všech procesů PHP.

**Kde má ležet adresář vendor?**  
V ideálním případě mimo veřejně dostupný webový adresář. Mnoho frameworků vkládá do webrootu jen adresář public, zatímco vendor leží o úroveň výš.

## Zdroje

- [Composer: Basic usage](https://getcomposer.org/doc/01-basic-usage.md)
- [Composer: Command-line interface](https://getcomposer.org/doc/03-cli.md)
- [Composer: The composer.json schema](https://getcomposer.org/doc/04-schema.md)