Менеджер пакетов

Современный проект редко пишется с нуля: отправка почты, работа с изображениями, клиент для API — всё это готовые библиотеки. У каждой есть свои зависимости, у тех — свои. Скачивать их вручную и следить за совместимостью версий нереально. Менеджер пакетов берёт эту работу на себя: разработчик указывает, что нужно, а инструмент находит подходящие версии в реестре и раскладывает файлы по местам.

Единица распространения — пакет: код библиотеки плюс описание с названием, версией и списком зависимостей.

Манифест и lock-файл

У менеджера два ключевых файла. Манифест (composer.json, package.json) перечисляет прямые зависимости с допустимыми диапазонами версий: запись ^7.8 означает «7.8 или новее, но не 8.0». Lock-файл (composer.lock, package-lock.json) фиксирует точные версии всего дерева, включая зависимости зависимостей. Его коммитят в репозиторий, чтобы на сервере и у коллег установилось ровно то же, что у вас.

Пример: Composer в проекте на PHP

composer require guzzlehttp/guzzle   # добавить пакет и записать в composer.json
composer install                     # поставить версии строго по composer.lock
composer update guzzlehttp/guzzle    # обновить пакет в пределах диапазона
composer audit                       # проверить известные уязвимости

После установки код подключается одной строкой require __DIR__ . '/vendor/autoload.php';, а классы загружаются автоматически. На боевом сервере выполняют composer install --no-dev, чтобы не тащить инструменты разработки.

Системные и языковые менеджеры

• Языковые работают внутри проекта: Composer для PHP, npm, Yarn и pnpm для JavaScript, pip для Python.
• Системные ставят программы в операционную систему: apt в Debian и Ubuntu, dnf в Fedora, Homebrew в macOS. Через apt на сервер ставят PHP, nginx и MariaDB, через Composer — библиотеки конкретного сайта.

Частая ошибка — запускать update на боевом сервере: туда приедут новые версии, которые никто не проверял. Обновляют локально, тестируют, коммитят lock-файл, а на сервере выполняют только install.