Composer: menedżer pakietów dla PHP

Krótko: Composer to menedżer pakietów dla PHP. Odczytuje z pliku composer.json, jakich bibliotek potrzebuje projekt, pobiera je do folderu vendor, zapisuje dokładne wersje w composer.lock i tworzy autoloader, który automatycznie znajduje klasy. Composer zarządza więc kodem Państwa aplikacji, a nie samym interpreterem PHP: aktualizacja Composera nie zamyka luki w PHP, takiej jak PHP2Shell.

Czym jest Composer i do czego jest potrzebny?

Dziś niemal żadna aplikacja PHP nie składa się wyłącznie z własnego kodu. Frameworki, biblioteki poczty, generowanie PDF czy integracje płatności dochodzą jako gotowe pakiety. Composer, menedżer pakietów dla PHP, dba o to, aby te pakiety trafiły razem w pasujących wersjach i aby każda zależność przynosiła ze sobą własne zależności.

Dla osób podejmujących decyzje oznacza to: duża część kodu działającego na Państwa serwerze pochodzi od osób trzecich. Jest to efektywne, ale wymaga pielęgnacji. Dla administratorów i programistów oznacza to: kto używa Composera starannie, może w każdej chwili prześledzić, jaka wersja której biblioteki działa na produkcji.

Standardowym źródłem pakietów jest według dokumentacji Composera Packagist.org. Dalsze źródła, na przykład wewnętrzne repozytoria agencji, można wpisać w composer.json w sekcji repositories.

composer.json, composer.lock i vendor: trzy elementy

Composer pracuje z trzema rzeczami, które warto znać, zanim przejmie się serwer lub zleci pracę agencji.

W require znajdują się pakiety, których aplikacja potrzebuje w eksploatacji. W require-dev są narzędzia do programowania i testów, na przykład frameworki testowe lub analiza statyczna. To rozdzielenie jest ważne, ponieważ narzędzia deweloperskie nie mają czego szukać na serwerze produkcyjnym.

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

Wersje w przykładzie wybrano tylko dla ilustracji. Jakich wersji potrzebuje Państwa projekt, wynika z jego wymagań.

install czy update: różnica w eksploatacji

Oba polecenia brzmią podobnie, ale mają bardzo różne skutki.

• composer install czyta composer.lock i instaluje dokładnie zapisane tam wersje. Jest to powtarzalne i należy do wdrożenia.
• composer update rozwiązuje wszystkie zależności od nowa, pobiera najnowsze pasujące wersje i zapisuje composer.lock na nowo. Należy to do programowania, z następującymi po tym testami.

Według dokumentacji Composera update wykonuje po zapisaniu pliku lock dodatkowo kontrolę bezpieczeństwa (audit), o ile nie wyłączy się jej opcją --no-audit. install domyślnie nie sprawdza; do tego służy opcja --audit.

Autoloading: jak Composer znajduje klasy

Composer tworzy plik vendor/autoload.php. Po jednorazowym dołączeniu PHP ładuje każdą klasę dopiero wtedy, gdy jest potrzebna. Dla własnego kodu w sekcji autoload określa się, który namespace leży w którym folderze. Zalecany jest do tego PSR-4, standard PHP-FIG. Jak to dokładnie działa, wyjaśnia strona Przestrzenie nazw i autoloading; przegląd wszystkich standardów daje strona Standardy PSR.

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

$log = new Monolog\Logger('app');   // ładowane automatycznie w razie potrzeby

Composer na produkcji: czyste wdrażanie

Przy wdrażaniu sprawdziła się stała kolejność. Najlepiej przebiega w potoku budowania (build pipeline), a nie ręcznie na serwerze.

1. Sprawdzić plik lock: composer validate zapewnia, że composer.json jest prawidłowy, a composer.lock aktualny.
2. Zainstalować bez pakietów deweloperskich: composer install --no-dev pomija require-dev.
3. Zoptymalizować autoloader: --optimize-autoloader (w skrócie -o) zamienia reguły na listę klas. Z --classmap-authoritative PHP ładuje klasy wyłącznie z tej listy.
4. Kontrola bezpieczeństwa: composer audit --locked sprawdza wersje z pliku lock względem znanych komunikatów bezpieczeństwa i zgłasza porzucone pakiety.
5. vendor poza katalogiem głównym WWW: Tylko folder publiczny ze skryptem wejściowym powinien być osiągalny przez URL.

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

composer outdated pokazuje dodatkowo, które zainstalowane pakiety mają nowsze wersje. To podstawa planowanych aktualizacji zamiast gorączkowych pojedynczych akcji.

Composer, bezpieczeństwo i PHP2Shell

Composer i PHP2Shell dotyczą dwóch różnych poziomów. Luki CVE-2026-109618 i CVE-2026-109619 tkwią w samym interpreterze PHP. Naprawiono je w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a po tym trzeba zrestartować wszystkie procesy PHP. Żaden composer update ani pakiet w vendor niczego tu nie zmienia.

Mimo to Composer należy do każdej kontroli po incydencie. Kto wprowadzi na serwer złośliwy kod, może zmienić także pliki w vendor, a vendor/autoload.php jest ładowany przy każdym żądaniu. Świeże composer install ze sprawdzonego pliku lock do pustego katalogu jest dlatego dobrą metodą przywrócenia zasobu pakietów. Jak regularnie sprawdzać zależności pod kątem znanych luk, opisuje poradnik composer audit.

Jak konkretnie pomaga PHP SOS?

• Ustalamy dla każdej aplikacji wersję PHP, pakiety Composera i stan pliku lock, oddzielając przy tym wyraźnie interpreter od bibliotek.
• Sprawdzamy, czy vendor i plik lock do siebie pasują oraz czy na produkcji nie leżą pakiety deweloperskie lub zmienione pliki.
• Konfigurujemy powtarzalne wdrażanie z install --no-dev, zoptymalizowanym autoloaderem i audytem.
• Po incydencie odtwarzamy zasób pakietów ze sprawdzonego pliku lock i dokumentujemy wynik.

Częste pytania

Źródła

• Composer: Basic usage
• Composer: Command-line interface
• Composer: The composer.json schema