# Composer: managerul de pachete pentru PHP

> Composer explicat: înțelegeți composer.json, composer.lock, vendor și autoloaderul, livrați curat în producție și întrețineți dependențele în siguranță.

Sursa: https://phpsos.de/ro/php/composer/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Composer este managerul de pachete pentru PHP. El citește din fișierul `composer.json` ce biblioteci are nevoie un proiect, le descarcă în directorul `vendor`, consemnează versiunile exacte în `composer.lock` și generează un autoloader care găsește automat clasele. Composer administrează astfel codul aplicației dumneavoastră, nu interpretorul PHP însuși: o actualizare Composer nu închide o vulnerabilitate din PHP precum PHP2Shell.

## Ce este Composer și la ce folosește?

Aproape nicio aplicație PHP de azi nu constă doar din cod propriu. Framework-uri, biblioteci de e-mail, generare de PDF sau conectări de plată vin ca pachete gata făcute. Composer, managerul de pachete pentru PHP, se asigură că aceste pachete ajung împreună în versiuni potrivite și că fiecare dependență își aduce propriile dependențe.

Pentru factorii de decizie asta înseamnă: o mare parte din codul care rulează pe serverul dumneavoastră provine de la terți. Este eficient, dar cere întreținere. Pentru administratori și dezvoltatori înseamnă: cine folosește Composer curat poate verifica oricând ce versiune a cărei biblioteci rulează în producție.

Sursa standard de pachete este, potrivit documentației Composer, Packagist.org. Alte surse, de exemplu repository-uri interne ale unei agenții, pot fi înscrise în `composer.json` la `repositories`.

## composer.json, composer.lock și vendor: cele trei componente

Composer lucrează cu trei lucruri pe care ar trebui să le cunoașteți înainte de a prelua un server sau de a angaja o agenție.

| Componentă | Conținut | Aparține repository-ului? |
|---|---|---|
| `composer.json` | pachetele dorite, cu intervale de versiuni (`require`, `require-dev`), reguli de autoload, setări | da |
| `composer.lock` | versiunile rezolvate exact ale tuturor pachetelor, inclusiv cele indirecte | da, explicit conform documentației Composer |
| `vendor/` | codul descărcat al pachetelor și autoloaderul generat | nu, se generează la instalare |

La `require` se află pachetele de care aplicația are nevoie în funcționare. La `require-dev` se află instrumente pentru dezvoltare și teste, de exemplu framework-uri de testare sau analiză statică. Această separare este importantă, deoarece instrumentele de dezvoltare nu au ce căuta pe un server de producție.

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

Indicațiile de versiune din exemplu sunt alese doar pentru ilustrare. Ce versiuni are nevoie proiectul dumneavoastră rezultă din cerințele lui.

## install sau update: diferența în exploatare

Cele două comenzi sună asemănător, dar au consecințe foarte diferite.

- `composer install` citește `composer.lock` și instalează exact versiunile consemnate acolo. Este reproductibil și aparține livrării.
- `composer update` rezolvă toate dependențele din nou, aduce cele mai noi versiuni potrivite și rescrie `composer.lock`. Aparține dezvoltării, cu teste ulterioare.

Potrivit documentației Composer, `update` execută după scrierea fișierului lock suplimentar o verificare de securitate (audit), dacă nu este dezactivată cu `--no-audit`. `install` nu verifică implicit; pentru aceasta există opțiunea `--audit`.

## Autoloading: cum găsește Composer clasele

Composer generează fișierul `vendor/autoload.php`. Odată inclus, PHP încarcă fiecare clasă abia atunci când este necesară. Pentru codul propriu se stabilește în secțiunea `autoload` ce namespace se află în ce director. Pentru aceasta este recomandat PSR-4, un standard al PHP-FIG. Cum funcționează exact explică pagina [Namespaces și autoloading](https://phpsos.de/ro/php/namespaces-autoloading/); o prezentare a tuturor standardelor oferă pagina [Standardele PSR](https://phpsos.de/ro/php/psr-standards/).

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

$log = new Monolog\Logger('app');   // se încarcă automat la nevoie
```

## Composer în producție: livrare curată

Pentru livrare s-a dovedit utilă o ordine fixă. Ea rulează cel mai bine într-un pipeline de build și nu manual pe server.

1. **Verificarea fișierului lock:** `composer validate` asigură că `composer.json` este valid și `composer.lock` este actual.
2. **Instalarea fără pachetele de dezvoltare:** `composer install --no-dev` omite `require-dev`.
3. **Optimizarea autoloaderului:** `--optimize-autoloader` (pe scurt `-o`) transformă regulile într-o listă de clase. Cu `--classmap-authoritative`, PHP încarcă clase exclusiv din această listă.
4. **Verificarea de securitate:** `composer audit --locked` verifică versiunile din fișierul lock față de avizele de securitate cunoscute și raportează pachetele abandonate.
5. **vendor în afara webroot:** Doar directorul public cu scriptul de intrare ar trebui să fie accesibil prin URL.

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

`composer outdated` arată suplimentar care pachete instalate au versiuni mai noi. Aceasta este baza pentru actualizări planificate în loc de acțiuni izolate făcute în grabă.

## Composer, securitate și PHP2Shell

Composer și PHP2Shell privesc două niveluri diferite. Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 se află în interpretorul PHP însuși. Ele sunt remediate în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35, iar după aceea toate procesele PHP trebuie repornite. Nicio comandă `composer update` și niciun pachet din `vendor` nu schimbă nimic în această privință.

Totuși, Composer aparține oricărei verificări de după un incident. Cine aduce cod malițios pe un server poate modifica și fișiere din `vendor`, iar `vendor/autoload.php` este încărcat la fiecare cerere. Un `composer install` proaspăt din fișierul lock verificat, într-un director gol, este de aceea o metodă bună de a reface stocul de pachete. Cum verificați regulat dependențele pentru vulnerabilități cunoscute descrie ghidul [composer audit](https://phpsos.de/ro/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Important:**
> Un `composer audit` verde nu spune nimic despre starea de patch a PHP. Verificați mediul de execuție PHP separat, de exemplu cu [serviciul nostru de patch PHP](https://phpsos.de/ro/leistungen/php-patch-service/).

## Cum ajută PHP SOS concret?

- Pentru fiecare aplicație inventariem versiunea PHP, pachetele Composer și starea fișierului lock, separând curat interpretorul de biblioteci.
- Verificăm dacă `vendor` și fișierul lock se potrivesc între ele și dacă în producție se află pachete de dezvoltare sau fișiere modificate.
- Configurăm o livrare reproductibilă cu `install --no-dev`, autoloader optimizat și audit.
- După un incident refacem stocul de pachete din fișierul lock verificat și documentăm rezultatul.


## Întrebări frecvente

**Trebuie composer.lock să intre în repository-ul Git?**  
Da. Documentația Composer recomandă explicit comiterea fișierului composer.lock. Doar așa dezvoltarea, CI și producția instalează exact aceleași versiuni de pachete.

**Care este diferența dintre composer install și composer update?**  
install instalează versiunile consemnate în composer.lock. update rezolvă dependențele din nou, aduce versiuni noi potrivite și rescrie composer.lock. Pe serverul de producție aparține doar install.

**Închide o actualizare Composer vulnerabilitatea PHP2Shell?**  
Nu. Composer administrează bibliotecile aplicației dumneavoastră, nu interpretorul PHP. PHP2Shell se închide doar prin actualizarea mediului de execuție PHP la o versiune corectată și repornirea tuturor proceselor PHP.

**Unde ar trebui să se afle directorul vendor?**  
Ideal în afara directorului web accesibil public. Multe framework-uri plasează în webroot doar un director public, în timp ce vendor se află cu un nivel mai sus.

## Surse

- [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)