# Composer: pakethanteraren för PHP

> Composer förklarat: förstå composer.json, composer.lock, vendor och autoloader, leverera rent till produktion och underhålla beroenden på ett säkert sätt.

Källa: https://phpsos.de/sv/php/composer/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** Composer är pakethanteraren för PHP. Den läser i filen `composer.json` vilka bibliotek ett projekt behöver, laddar ned dem i mappen `vendor`, fastlägger de exakta versionerna i `composer.lock` och skapar en autoloader som hittar klasser automatiskt. Composer förvaltar alltså er applikations kod, inte själva PHP-tolken: En Composer-uppdatering täpper inte till en sårbarhet i PHP som PHP2Shell.

## Vad är Composer och vad behövs det till?

Knappt någon PHP-applikation består i dag bara av egen kod. Ramverk, e-postbibliotek, PDF-generering eller betalningsanslutningar tillkommer som färdiga paket. Composer, pakethanteraren för PHP, ser till att paketen kommer ihop i passande versioner och att varje beroende tar med sina egna beroenden.

För beslutsfattare betyder det: En stor del av koden som körs på er server kommer från tredje part. Det är effektivt men kräver underhåll. För administratörer och utvecklare betyder det: Den som använder Composer rent kan när som helst spåra vilken version av vilket bibliotek som körs i produktionen.

Standardkällan för paket är enligt Composer-dokumentationen Packagist.org. Andra källor, till exempel en byrås interna förråd, kan anges i `composer.json` under `repositories`.

## composer.json, composer.lock och vendor: de tre byggstenarna

Composer arbetar med tre saker som man bör känna till innan man tar över en server eller anlitar en byrå.

| Byggsten | Innehåll | Hör hemma i förvaret? |
|---|---|---|
| `composer.json` | önskade paket med versionsintervall (`require`, `require-dev`), autoload-regler, inställningar | ja |
| `composer.lock` | exakt upplösta versioner av alla paket, även de indirekta | ja, uttryckligen enligt Composer-dokumentationen |
| `vendor/` | nedladdad kod från paketen och den skapade autoloadern | nej, skapas vid installationen |

Under `require` står paket som applikationen behöver i drift. Under `require-dev` står verktyg för utveckling och tester, till exempel testramverk eller statisk analys. Den här uppdelningen är viktig eftersom utvecklingsverktyg inte hör hemma på en produktionsserver.

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

Versionsuppgifterna i exemplet är valda bara för att illustrera. Vilka versioner ert projekt behöver framgår av dess krav.

## install eller update: skillnaden i drift

De båda kommandona låter lika men får mycket olika följder.

- `composer install` läser `composer.lock` och installerar exakt de versioner som är fastlagda där. Det är reproducerbart och hör hemma i leveransen.
- `composer update` löser alla beroenden på nytt, hämtar de nyaste passande versionerna och skriver om `composer.lock`. Det hör hemma i utvecklingen, med efterföljande tester.

Enligt Composer-dokumentationen kör `update` efter att lock-filen skrivits dessutom en säkerhetskontroll (audit), om den inte stängs av med `--no-audit`. `install` kontrollerar inte som standard; för det finns alternativet `--audit`.

## Autoloading: så hittar Composer klasser

Composer skapar filen `vendor/autoload.php`. När den väl har inkluderats laddar PHP varje klass först när den behövs. För egen kod anges i avsnittet `autoload` vilken namnrymd som ligger i vilken mapp. Rekommenderat är PSR-4, en standard från PHP-FIG. Hur det fungerar förklaras på sidan [Namnrymder och autoloading](https://phpsos.de/sv/php/namespaces-autoloading/); en översikt över alla standarder ger sidan [PSR-standarder](https://phpsos.de/sv/php/psr-standards/).

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

$log = new Monolog\Logger('app');   // laddas automatiskt vid behov
```

## Composer i produktion: leverera rent

För leveransen har en fast ordningsföljd visat sig fungera. Den körs bäst i en build-pipeline och inte för hand på servern.

1. **Kontrollera lock-filen:** `composer validate` säkerställer att `composer.json` är giltig och `composer.lock` aktuell.
2. **Installera utan utvecklingspaket:** `composer install --no-dev` utelämnar `require-dev`.
3. **Optimera autoloadern:** `--optimize-autoloader` (förkortat `-o`) omvandlar reglerna till en klasslista. Med `--classmap-authoritative` laddar PHP klasser uteslutande från den listan.
4. **Säkerhetskontroll:** `composer audit --locked` kontrollerar versionerna i lock-filen mot kända säkerhetsmeddelanden och rapporterar övergivna paket.
5. **vendor utanför webbroten:** Bara den publika mappen med startskriptet bör vara nåbar via URL.

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

`composer outdated` visar dessutom vilka installerade paket som har nyare versioner. Det är grunden för planerade uppdateringar i stället för hektiska enskilda insatser.

## Composer, säkerhet och PHP2Shell

Composer och PHP2Shell berör två olika nivåer. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 ligger i själva PHP-tolken. De är åtgärdade i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35, och alla PHP-processer måste därefter startas om. Ingen `composer update` och inget paket i `vendor` ändrar något i det.

Ändå hör Composer hemma i varje granskning efter en incident. Den som för in skadlig kod på en server kan också ändra filer i `vendor`, och `vendor/autoload.php` laddas vid varje förfrågan. En ny `composer install` från den kontrollerade lock-filen till en tom katalog är därför en bra metod för att återställa paketbeståndet. Hur ni regelbundet kontrollerar beroenden mot kända sårbarheter beskrivs i guiden [composer audit](https://phpsos.de/sv/ratgeber/composer-abhaengigkeiten-pruefen/).

> **Viktigt:**
> Ett grönt `composer audit` säger ingenting om PHP:s patchnivå. Kontrollera PHP-körmiljön separat, till exempel med vår [PHP-patchtjänst](https://phpsos.de/sv/leistungen/php-patch-service/).

## Hur hjälper PHP SOS konkret?

- Vi tar fram PHP-version, Composer-paket och lock-läge för varje applikation och skiljer därvid rent mellan tolk och bibliotek.
- Vi kontrollerar att `vendor` och lock-filen stämmer överens och om utvecklingspaket eller ändrade filer ligger i produktionen.
- Vi inrättar en reproducerbar leverans med `install --no-dev`, optimerad autoloader och audit.
- Efter en incident återskapar vi paketbeståndet från den kontrollerade lock-filen och dokumenterar resultatet.


## Vanliga frågor

**Måste composer.lock in i Git-förvaret?**  
Ja. Composer-dokumentationen rekommenderar uttryckligen att committa composer.lock. Bara så installerar utveckling, CI och produktion exakt samma paketversioner.

**Vad är skillnaden mellan composer install och composer update?**  
install installerar de versioner som är fastlagda i composer.lock. update löser beroendena på nytt, hämtar passande nyare versioner och skriver om composer.lock. På produktionsservern hör bara install hemma.

**Täpper en Composer-uppdatering till PHP2Shell-sårbarheten?**  
Nej. Composer förvaltar bibliotek i er applikation, inte PHP-tolken. PHP2Shell täpps bara till genom en uppdatering av PHP-körmiljön till en åtgärdad version och omstart av alla PHP-processer.

**Var bör vendor-mappen ligga?**  
Helst utanför den offentligt nåbara webbkatalogen. Många ramverk lägger bara en public-mapp i webbroten, medan vendor ligger en nivå ovanför.

## Källor

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