# Composer: menedżer pakietów dla PHP

> Composer wyjaśniony: composer.json, composer.lock, vendor i autoloader, czyste wdrażanie na produkcję oraz bezpieczne utrzymywanie zależności.

Źródło: https://phpsos.de/pl/php/composer/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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.

| Element | Zawartość | Czy należy do repozytorium? |
|---|---|---|
| `composer.json` | żądane pakiety z zakresami wersji (`require`, `require-dev`), reguły autoload, ustawienia | tak |
| `composer.lock` | dokładnie rozwiązane wersje wszystkich pakietów, także pośrednich | tak, według dokumentacji Composera wyraźnie |
| `vendor/` | pobrany kod pakietów i wygenerowany autoloader | nie, powstaje przy instalacji |

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.

```json
{
    "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](https://phpsos.de/pl/php/namespaces-autoloading/); przegląd wszystkich standardów daje strona [Standardy PSR](https://phpsos.de/pl/php/psr-standards/).

```php
<?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.

```bash
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](https://phpsos.de/pl/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Ważne:**
> Zielony wynik `composer audit` nic nie mówi o stanie poprawek PHP. Proszę sprawdzać środowisko uruchomieniowe PHP osobno, na przykład z naszą [usługą PHP Patch Service](https://phpsos.de/pl/leistungen/php-patch-service/).

## 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

**Czy composer.lock musi trafić do repozytorium Git?**  
Tak. Dokumentacja Composera wyraźnie zaleca commitowanie composer.lock. Tylko tak programowanie, CI i produkcja instalują dokładnie te same wersje pakietów.

**Jaka jest różnica między composer install a composer update?**  
install instaluje wersje zapisane w composer.lock. update rozwiązuje zależności od nowa, pobiera pasujące nowsze wersje i zapisuje composer.lock na nowo. Na serwerze produkcyjnym należy używać tylko install.

**Czy aktualizacja Composera zamyka lukę PHP2Shell?**  
Nie. Composer zarządza bibliotekami Państwa aplikacji, a nie interpreterem PHP. PHP2Shell zamyka tylko aktualizacja środowiska uruchomieniowego PHP do naprawionej wersji i restart wszystkich procesów PHP.

**Gdzie powinien leżeć folder vendor?**  
Najlepiej poza publicznie dostępnym katalogiem WWW. Wiele frameworków umieszcza w tym celu w katalogu głównym WWW tylko folder public, a vendor leży poziom wyżej.

## Źródła

- [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)
