Кратко
Composer сделал PHP-экосистему модульной: проект описывает зависимости в `composer.json`, а Composer скачивает пакеты, строит autoload и фиксирует версии.
Что это такое
Composer — менеджер зависимостей для PHP. Он помогает объявлять, устанавливать и обновлять библиотеки проекта, а публичные пакеты обычно ищутся через Packagist.
Что внутри
Репозиторий содержит сам Composer, resolver зависимостей, поддержку lock-файла, autoload-генерацию, документацию и тесты. Есть основная ветка Composer 2 и LTS-линия 2.2.
Как используют
Composer используют почти в каждом современном PHP-проекте: фреймворки, библиотеки, консольные инструменты и расширения ставятся через одну понятную модель, а Packagist служит общей точкой поиска публичных пакетов.
Пример
composer.json
Пример показывает минимальное описание пакета и зависимости, которую Composer установит в vendor.
{
"require": {
"guzzlehttp/guzzle": "^7.0"
},
"autoload": {
"psr-4": { "App\\\\": "src/" }
}
}Сильные стороны
Сильная сторона Composer — воспроизводимость. `composer.lock` фиксирует конкретные версии, а autoload позволяет не писать ручные include для каждого класса.
Ограничения
Ограничение — дисциплина зависимостей. Слишком широкие версии, забытый lock-файл или бесконтрольные пакеты могут сделать обновления рискованными.
Контекст проекта
Composer ведется в репозитории composer/composer; публичная история проекта начинается 2011-06-08. Основной язык в метаданных — PHP, лицензия — MIT. У проекта есть отдельный сайт: https://getcomposer.org/.
Этот контекст помогает читать страницу как разбор конкретного репозитория: у проекта есть владелец, техническая база, лицензия, история изменений и реальные ограничения выбранной экосистемы.
Composer стоит оценивать через конкретный сценарий: кто будет поддерживать инструмент, где он встраивается в существующий стек, какие обновления придется отслеживать и что произойдет при ошибке. Такой взгляд лучше простой установки ради популярности, потому что открытый проект приносит пользу только тогда, когда его место в системе понятно команде.
Перед внедрением полезно отдельно проверить документацию, частоту релизов, модель лицензирования, требования к окружению и то, насколько легко проект будет удалить или заменить, если выбранный путь перестанет подходить продукту.