Разработка PHP проектов с пакетным менеджером Composer | Блог Work Solutions
Почему PHP Composer –это больше, чем просто менеджер зависимостей
ГлавнаяБлогРазработчикамПочему PHP Composer –это больше, чем просто менеджер зависимостей
Разработчикам26 июля 2023

Почему PHP Composer –это больше, чем просто менеджер зависимостей

Фотография автора
Павел ГапоненкоBackend-разработчик

В настоящее время сложно представить проект без менеджера зависимостей, независимо от того, на каком языке программирования он написан. Для PHP таким менеджером является Composer.

Цель данной статьи – не только познакомить вас с пакетным менеджером Composer, но и рассказать немного больше, чем просто о способах установки и обновления сторонних пакетов.

Что такое Composer?

Composer - это инструмент для управления сторонними библиотеками в PHP-проекте. Он позволяет подключать, устанавливать и обновлять библиотеки или «пакеты», а также управлять их версиями.

Разработка Composer была вдохновлена уже существующими на тот момент менеджерами пакетов: npm (Node.js) и bundler (Ruby). Первый релиз состоялся 1 марта 2012 года.

Composer кроссплатформенный инструмент: он одинаково работает на операционных системах Windows, Linux и OSX.

Чем Composer отличается от Pear

До появления Composer в мире PHP-разработки существовал PEAR (PHP Extension and Application Repository) – это фреймворк и система распространения повторно используемых PHP-компонентов.

PEAR позволял создавать библиотеки на PHP, хранить их в общем репозитория и использовать в проектах. Для чего же понадобилась разработка нового менеджера зависимостей?

Дело в том, что у PEAR есть несколько существенных минусов:

  1. Библиотека устанавливается в масштабе всей системы, а не для каждого проекта отдельно, таким образом, невозможно использовать несколько разных версий одной библиотеки на компьютере.
  2. Чтобы загрузить библиотеку в PEAR, необходимо набрать определенное количество голосов.
  3. Существующие решения были часто устаревшими, неактивными или неподдерживающимися.

Основы использования Composer

Простое управление библиотеками и пакетами в PHP-проекте.

Для быстрого старта разработчику нужно знать всего несколько команд, например:

init – инициализация проекта (а зачастую она не требуется при использовании PHP-фреймворка);

require – подключить пакет;

install – установить зависимости;

update – обновить пакеты;

При использовании этих команд можно легко продолжить работу над проектом, не вдаваясь в подробности. Также есть подробная официальная документация, там можно прочесть всю необходимую информацию по установке и использованию.

Но Composer – это больше, чем просто пакетный менеджер. Чтобы в этом разобраться, для начала пройдемся по основам использования:

Composer.json

Центральный файл для управления – composer.json. В нем описываются различные настройки и, самое главное, пакеты, от которых зависит наш проект:

Изображение статьи

В блоке require указываются необходимые нам пакеты, но их также можно добавить и с помощью команды:

Изображение статьи

Версии пакетов

Большинство разработчиков при разработке своих пакетов следуют соглашению SemVer – семантическое версионирование. Это соглашение, при котором номер версии указывается в следующем виде:

| MAJOR.MINOR.PATCH,

где MAJOR, MINOR и PATСH - целые числа, начиная с 0.

Когда следует увеличивать версию:

  • Major (мажорная версия) - обратно несовместимые изменения в API.
  • Minor (минорная версия) - добавлена функциональность и при этом не нарушена обратная совместимость.
  • Patch (патч-версия) - баг-фиксы, незначительные доработки.

Некоторые способы указания версий в composer.json:

Точная версия

"worksolutions/php-collections""1.1.7"

Диапазон версий

"worksolutions/php-collections"">=1.0.0"

Диапазон тильды

"worksolutions/php-collections""~1.2.3"

Эквивалентно >=1.2.3 <1.3.0

Диапазон каретки

"worksolutions/php-collections""^1.2.3"

Эквивалентно >=1.2.3 <2.0.0. Используется для ограничения мажорной версии, чтобы гарантировать обратную совместимость

Диапазон версий подстановочных знаков

"worksolutions/php-collections""1.0.*"

Эквивалентно >=1.0.0 <1.1

Также, в качестве версии можно указать название ветки или хэш коммита, если в качестве поставщика пакета используется git-репозиторий.

Файл блокировки

При первой установке всех пакетов в проект, которые описаны в composer.json будет создан файл composer.lock, в котором будут указаны точные версии каждого из установленных. 

При следующей попытке установки будет браться информация из файла блокировки, загружая точные версии каждого пакета, чтобы не допустить случайных ошибок из-за новых минорных обновлений.

Рекомендуется сохранять файл composer.lock в системе контроля версий.

Основные команды

Инициализация проекта

composer init

Установка пакетов

composer install

При первом запуске будет взята информация из файла composer.json, затем создается файл composer.lock, на основе которого и происходит установка.

Обновление

composer update

Выполняет установку пакетов как будто файла composer.lock не существует. Пакетный менеджер сделает установку согласно composer.json, а затем обновит composer.lock.

Обновление

composer require

Добавит пакет в composer.json

Автозагрузка

Чтобы использовать классы проекта или установленных библиотек, необходимо подключить сгенерированный файл:

Изображение статьи

Пример autoload в файле composer.json:

Изображение статьи

Данную запись можно понимать следующим образом: класс, который имеет путь src/Service/Logger.php будет иметь пространство имен App\Service.

Подключить данный класс можно с использованием директивы use:

Изображение статьи

Пакеты

Каждый проект по сути является пакетом. С разницей лишь в том, что название библиотеки обязательное, а проекта нет.

Способы подключения пакетов

Существует немало различных способов подключить библиотеку в проект. Так, библиотеку можно подключить, если она доступна через VCS (систему контроля версий), либо использовать прямую ссылку на zip-файл с пакетом.

Подключение пакетов, опубликованных на Packagist, удобный, простой и распространенный метод.

Packagist - это репозиторий Composer. Опубликованные там пакеты можно подключить в проект, не указывая никакой дополнительной информации, кроме названия и версии в блоке require. Необходимо, чтобы он предварительно был опубликован на packagist.org.

Рассмотрим подключение библиотеки PHP-коллекций через git-репозиторий:

Изображение статьи

Для подключения в блоке require необходимо указать название репозитория и ветку, а в блоке repositories добавить ссылку на репозиторий.  

Данный способ выглядит несложным, однако, проще подключать библиотеки, которые хранятся на Packagist. Рассмотрим пример подключения той же библиотеки, но через Packagist:

Изображение статьи

Репозиторий Packagist не нужно специально указывать в Composer - он зарегистрирован там по-умолчанию.

Создание собственного пакета

Создание репозитория

Перед тем, как начать разработку нашего пакета, создадим репозиторий на GitHub:

Изображение статьи

Клонируем репозиторий и переходим в папку проекта

Изображение статьи

Перед началом инициализации проекта необходимо создать файл .gitignore, где нужно указать директорию vendor, а также файл блокировки composer.lock. Это необходимо для того, чтобы пользователь мог развернуть любую подходящую версию пакета.

Инициализация проекта

Генерируем конфигурационный файл, выполнив команду инициализации

Изображение статьи

Далее отвечаем на вопросы, именуем пакет в формате <vendor>/<name>, где vendor - имя автора, например, имя пользователя на Github, name - имя пакета.

Тип указываем library, без указания, на данном этапе, дополнительных пакетов.  

В итоге при завершении работы команды будет создан файл composer.json:

Изображение статьи

Создание файла README

Рекомендуется в файле README.md указать:

  • Название
  • Доступную версию PHP
  • Способ установки
  • Примеры использования 

Изображение статьи

Версионирование

Версии пакета добавляются с помощью команды git tag.

Пример:

Создаем тег

Изображение статьи

Отправляем тег в репозиторий

Изображение статьи

Добавлен тег: 

Изображение статьи

Публикация пакета на Packagist

Переходим на сайт packagist.org, выбираем «Submit».

Указываем ссылку на репозиторий Github и выполняем проверку:

Изображение статьи

После проверки снова нажимаем «Submit» и пакет будет опубликован: 

Изображение статьи

Скрипты Composer

Скрипт - это определенный сценарий, который выполняется по какому-либо событию, например, установка зависимостей или сброс автозагрузчика.

Таким сценарием может быть любой набор команд командной строки или статический метод PHP-класса.

Существует несколько видов событий:

  • Командные события 
  • События установщика
  • События пакета
  • События плагина

Определение сценариев

Чтобы определить сценарий, в файле composer.json добавляется свойство scripts, которое содержит пары «событие» - «сценарий». Сценарий может быть объявлен как строка для выполнения одного действия или как массив для указания нескольких скриптов.

Пример объявления скрипта как статический метод PHP:

Изображение статьи

Пример объявления скрипта как команда командной строки:

Изображение статьи

Запуск скриптов и пользовательские команды

При необходимости скрипты можно запустить вручную, а не использовать их только при возникновении какого-либо события.

Например, команда:

Изображение статьи

запустит все сценарии, которые определены для события post-install-cmd.

Если существует необходимость добавить пользовательский сценарий, но все доступные события не подходят под этот сценарий, то существует возможность определить под собственным именем.

Пример:

Изображение статьи

Запустить скрипт можно с помощью команды run-script, либо как собственную команду composer:

Изображение статьи

Плагины Composer

Плагин - это обычный пакет, который используется для расширения функциональности при необходимости.

Основное отличие заключается в том, что в composer.json пакет плагина должен иметь тип composer-plugin, атрибут extra должен содержать один или множество классов плагина, а также должен быть подключен специальный пакет composer-plugin-api.

Плагин подключается в проект как обычный пакет Composer. Он также должен быть загружен на Packagist.

Пример:

Изображение статьи

Создание плагина

Каждый плагин должен реализовывать интерфейс PluginInterface. 

Интерфейс содержит методы, в которые передаются экземпляры классов Composer\Composer и Composer\IO\IOInterface.  

С помощью этих двух объектов можно прочитать всю конфигурацию, а также управлять всеми внутренними объектами и состоянием.

Также, плагины могут реализовывать EventSubscriberInterface для автоматической регистрации обработчиков событий при загрузке плагина.

Пример класса плагина с обработками события:

Изображение статьи

Возможности плагина

Composer предоставляет так называемый набор возможностей, которые могут быть реализованы плагинами. Их цель состоит в том, чтобы расширить имеющиеся возможности, не прибегая к изменению внутреннего состояния экземпляра класс Composer. 

Чтобы добавить использование возможностей, класс плагина должен реализовывать интерфейс Capable. Данный интерфейс содержит метод getCapabilities(), который возвращает массив с ключом в качестве имени класса Composer Capability и значением в виде собственного имени класса реализации плагина указанной возможности.

Пример реализации собственного поставщика команд.

Команда:

Изображение статьи

Поставщик команд:

Изображение статьи

После этого в проекте, где подключен плагин, можно использовать команду:

Изображение статьи

Выводы

  • Composer - это не просто менеджер пакетов, но и удобный инструмент для управления PHP-проектом. 
  • Большой ряд дополнительных возможностей, которые могут быть полезны при разработке проектов на PHP.
  • Лучшим способом погружения в какой-либо инструмент является изучение его официальной документации.
1.3к
119

Другие статьи

Ко всем статьям
Фоновое изображение: четверть круга закрыват часть круга

Интересные статьи и кейсы
от Work Solutions

Нажимая кнопку «Подписаться», я даю согласие на обработку персональных данных

Спасибо за подписку!

Фоновое изображение: верхний полукруг