Расширенные сведения о Composer

2.12. Расширенные сведения о Composer

Ранее в этой главе мы использовали Composer, чтобы установить код библиотеки Zend Framework 3. Теперь вкратце опишем некоторые продвинутые примеры использования Composer'a.

Как мы уже знаем, единственный необходимый ключ в файле composer.json это require. Он сообщает, какие пакеты требуются вашему приложению.

{
    "require": {
        "php": "^5.6 || ^7.0",
        "zendframework/zend-component-installer": "^1.0 || ^0.3 || ^1.0.0-dev@dev",
        "zendframework/zend-mvc": "^3.0.1",
        "zfcampus/zf-development-mode": "^3.0",
        "zendframework/zend-mvc-form": "^1.0",
        "zendframework/zend-mvc-plugins": "^1.0.1",
        "zendframework/zend-session": "^2.7.1"
    }
}

2.12.1. Имена и версии пакетов

Имя пакета состоит из двух частей: имени поставщика и имени проекта. Например, имя пакета "zendframework/zend-mvc" состоит из имени поставщика "zendframework" и имени проекта "zend-mvc". Другие пакеты от поставщика "zendframework" вы можете найти на сайте Packagist.org (см. рисунок 2.8).

Рисунок 2.8. Пакеты можно найти на Packagist.org

Пакет также имеет номер версии. Он состоит из: главного (major) номера, вспомогательного (minor) номера, номера сборки (необязательно) и суффикса (например, b1, rc1; также необязательно). В ключе require мы указываем, какие версии пакета допустимы. Например, "^5.6" означает, что мы можем установить версии новее 5.6, но позднее 6.0. (мы можем установить только те пакеты, которые не нарушают обратную совместимость). В таблице 2.2 представлены возможные способы указания допустимых версий.

Таблица 2.2. Определения версии пакета

Пример определения	Описание
3.0.1	Конкретная версия. В этом примере можно установить только версию 3.0.1.
>=3.0.1	Эта или более поздние версии могут быть установлены. (3.0.1, 3.2.1, etc.)
>3.0.1	Только более поздние версии могут быть установлены. (3.0.2 etc.)
<=3.0.1	Эта или более ранние версии могут быть установлены. (1.0, 1.5, 2.0.0 etc.)
<3.0.1	Только более ранние версии могут быть установлены. (1.0, 1.1, 1.9, etc.)
!=3.0.1	Все версии, кроме этой, могут быть установлены.
>=3.0,<3.1.0	Любая версия из этого диапазона может быть установлена.
3.*	Любая версия с главным номером 3 может быть установлена (вспомогательный номер может быть любым).
~3.0	Любая версия, начиная от 3.0. до версии со следующим главным номером (эквивалентно >=3.0,<4.0).
^3.0	Любая версия, начиная от 3.0. до версии со следующим главным номером (эквивалентно >=3.0,<4.0). Работает аналогично `~3.0`, но ближе к семантическому управлению версиями.

2.12.2. Установка и обновление пакетов

Итак, мы посмотрели, как использовать команду php composer.phar install для установки зависимостей. Как только вы вызываете эту команду, Composer найдет, загрузит и установит зависимости в подкаталог vendor.

Безопасно ли устанавливать зависимости через Composer?

Вообще, некоторые люди побаиваются управления зависимостями с помощью Composer'a, потому что думают, что кто-нибудь может обновить зависимости для всей системы случайно или специально, нарушив при этом работу веб-приложения. Заметьте, Composer никогда не устанавливает их для всей системы, только в каталог APP_DIR/vendor/.

После установки Composer также создает файл APP_DIR/composer.lock. Он содержит актуальные версии установленных пакетов. Если вы снова запустите команду install, Composer столкнется с файлом composer.lock, проверит, какие зависимости уже были установлены, и, так как все пакеты уже установлены, выйдет, ничего не делая.

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

php composer.phar update

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

php composer.phar update zendframework/zend-mvc

После команды update файл composer.lock также обновится.

Что делать, если я захочу вернуться к предыдущей версии пакета?

Если обновление привело к нежелательным проблемам с вашей системой, вы можете откатить ее, отменив изменения файла composer.lock и снова запустив команду install. Отменить изменения composer.lock довольно просто, если вы используете систему контроля версий, например, GIT или SVN. Если вы не хотите использовать систему контроля версий, сделайте резервную копию файла composer.lock перед обновлением.

2.12.3. Добавление новой зависимости

Если вы хотите добавить новую зависимость в приложение, вы можете либо вручную изменить composer.json, либо запустить команду require. Например, чтобы установить модуль ORM Doctrine на ваш сайт (чтобы добавить пакет "doctrine/doctrine-module" к зависимостям приложения), напишите:

php composer.phar require doctrine/doctrine-module

Эта команда изменяет файл composer.json и загружает и устанавливает пакет. Мы будем использовать ее позже в главе Управление базой данных с Doctrine

2.12.4. Виртуальные пакеты

Composer можно использовать для того, чтобы потребовать каких-то дополнительных функций для вашей системы. Выше мы уже требовали "php:^5.6". Пакет PHP - это виртуальный пакет, представляющий, собственно, сам PHP. Вам также может понадобиться и другие материалы, например, расширения PHP (см. таблицу 2.3).

Таблица 2.3. Виртуальные пакеты Composer

Пример определения	Описание
"php":"^5.6"	Требует версию PHP 5.6 или новее, но не позже 6.0.
ext-dom, ext-pdo-mysql	Требует расширения PHP DOM и PDO MySQL.
lib-openssl	Требует библиотеку OpenSSL

Вы можете использовать команду php composer.phar show --platform для отображения списка доступных для вашей машины виртуальных пакетов.

2.12.5. Composer и системы контроля версий

Если вы используете систему контроля версий (например, Git), вам наверняка будет интересно, что должно там храниться: только код вашего приложения или код приложения плюс все установленные Composer'ом в каталог APP_DIR/vendor зависимости?

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

Что если какая-нибудь зависимость будет объявлена устаревшей и удалена с Packagist.org?

Вообще, вероятность удаления пакета минимальна. Все пакеты бесплатны и с открытым исходным кодом, и сообщество пользователей всегда может восстановить зависимость, даже если она была удалена с Packagist. Кстати, такая же концепция установки зависимостей используется в in Linux (помните менеджеры APT и RPM?) - а пакеты Linux когда-нибудь терялись?

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

Если вам нужно вносить свои изменения в сторонний код. Например, предположим, вам нужно исправить баг в библиотеке, и вы не можете ждать, пока поставщик библиотеки исправит его для вас (или он просто не может этого сделать). В этом случае, вам следует положить библиотеку под контроль версий, чтобы не потерять сделанные вами изменения.
Если вы написали модуль (или библиотеку), которую будете многократно использовать, и хотите хранить его в каталоге vendor без развертывания на Packagist.org. Так как вы не можете установить этот код с Packagist, его следует хранить под контролем версий.
Если вы хотите 100%-ную гарантию того, что сторонний пакет не будет утерян. Хотя риск этого минимален, некоторым приложениям необходимо быть автономными и не зависеть от доступности пакетов на Packagist.org.