Псевдонимы

Зачем нужны псевдонимы?

При работе с репозиторием VCS вы получите сравнимые версии только для ветвей, которые выглядят как версии, например, 2.0 или 2.0.x. Для вашей master ветви вы получите версию dev-master. Для вашей bugfix ветви вы получите версию dev-bugfix.

Если ваша master ветвь используется для тегирования релизов 1.0 линии разработки, т.е. 1.0.1, 1.0.2, 1.0.3, и т.д., любой пакет, зависящий от неё, скорее всего, потребует версии 1.0.*.

Если кто-то захочет потребовать последнюю dev-master, у них возникнет проблема: другие пакеты могут потребовать 1.0.*, поэтому требование этой версии разработки приведёт к конфликтам, так как dev-master не соответствует ограничению 1.0.*.

Введите псевдонимы.

Псевдоним ветви

Ветка dev-master находится в вашем главном репозитории VCS. Довольно часто кто-то хочет получить последнюю версию разработки из ветки master. Поэтому Composer позволяет вам создать псевдоним для вашей dev-master ветви, присвоив ей версию 1.0.x-dev. Это делается путем указания поля branch-alias в extra в composer.json:

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

Если вы создаёте псевдоним для несравнимой версии (например, dev-develop), dev- должен предшествовать имени ветви. Вы также можете создать псевдоним для сравнимой версии (т.е. начинающейся и заканчивающейся цифрами .x-dev), но только как более специфическую версию. Например, 1.x-dev можно сделать псевдонимом 1.2.x-dev.

Псевдоним должен быть сравнимой версией разработки, и branch-alias должен присутствовать в ветке, на которую он ссылается. Для dev-master, необходимо сделать коммит в ветке master.

В результате, любой теперь может потребовать 1.0.* и он без проблем установит dev-master.

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

Встроенный псевдоним

Псевдонимы ветвей отлично подходят для псевдонимизации основных линий разработки. Но для их использования вам нужно иметь контроль над исходным репозиторием и нужно внести изменения в систему контроля версий.

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

По этой причине вы можете создавать псевдонимы пакетов в полях require и require-dev. Предположим, вы обнаружили ошибку в пакете monolog/monolog. Вы клонировали Monolog на GitHub и исправили проблему в ветке, названной bugfix. Теперь вы хотите установить эту версию monolog в свой локальный проект.

Вы используете symfony/monolog-bundle, который требует версию monolog/monolog пакета 1.*. Таким образом, вам нужно, чтобы ваш dev-bugfix соответствовал этому ограничению.

Добавьте это в корневую папку проекта composer.json:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/you/monolog"
        }
    ],
    "require": {
        "symfony/monolog-bundle": "2.0",
        "monolog/monolog": "dev-bugfix as 1.0.x-dev"
    }
}

Или позвольте Composer добавить его для вас с помощью:

php composer.phar require "monolog/monolog:dev-bugfix as 1.0.x-dev"

Это позволит получить версию dev-bugfix пакета monolog/monolog с вашего GitHub и создать для неё псевдоним 1.0.x-dev.

Примечание: Встроенные псевдонимы — это функция только для корневого уровня. Если пакет с встроенными псевдонимами требуется, псевдоним (справа от as) используется как ограничение версии. Часть слева от as игнорируется. Вследствие этого, если пакет A требует пакет B, а B требует версию monolog/monolog пакета dev-bugfix as 1.0.x-dev, установка пакета A заставит пакет B потребовать версию 1.0.x-dev, которая может существовать как псевдоним ветви или как фактическая ветвь 1.0. Если её нет, её необходимо снова создать встроенным псевдонимом в composer.json.

Примечание: Следует избегать встроенных псевдонимов, особенно для опубликованных пакетов/библиотек. Если вы обнаружили ошибку, попробуйте получить исправление, слив его в основной репозиторий. Это помогает избежать проблем для пользователей вашего пакета.