Использование алиасов (псевдонимов) в Composer
Использование псевдонимов (aliases) в Composer
  1. Зачем нужны псевдонимы в Composer?
  2. Алиас ветви в Composer
  3. Обязательный внутренний псевдоним (inline-alias)

Старт! Честный VDS/VPS, на котором «Лунная База» живет уже 20+ лет

Задумываетесь о том, чтобы поднять свой pet-проект, сайт клиента или настроить окружение для разработки? Уже пора подумать, где арендовать железо.

Лунная База хостится на FirstVDS более 20 лет. Мыслей о том, чтобы перебраться на другой хостинг, не было ни разу (хотя опыт работы с другими вариантами, конечно, есть).

Бывали разные ситуации, но они бывают на любом железе. Главное, что нужно понять: здесь нет маркетинговой шелухи и сказок про «мы всё сделаем за вас». Если вы берете VDS — вам дают полный root, возможность накатить любую ОС и не лезут в ваши конфиги.

Если в саппорт написать с вопросом по вашему коду и получить ответ: «Читайте документацию и разбирайтесь сами» или «Обратитесь к профильному специалисту» — это не повод обижаться. Это повод углубить свои знания в DevOps и сайтостроении! Бегите от тех, кто пообещает: «Мы всё чиним и настраиваем абсолютно бесплатно!». Никто никогда не работает «по доброте душевной» в ущерб себе, а бесплатный сыр в администрировании обычно заканчивается сломанной базой данных.

Что по факту: Гибкое масштабирование ядер и RAM, экономия по сравнению с физическими серверами и адекватная панель ispmanager, если она вам нужна.



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

При использовании 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.*.

В этом случае в Composer используются псевдонимы.

Алиас ветви в Composer.

Ветка dev-master — это ветка в вашем основном репозитории VCS. Довольно часто бывает, что кто-то хочет получить последнюю версию dev-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.

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

Обязательный внутренний псевдоним (inline-alias).

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

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

Для этого вы можете использовать псевдонимы пакетов в полях 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 как 1.0.x-dev, установка A заставит B потребовать 1.0.x-dev, которая может существовать как псевдоним ветки или как фактическая ветка 1.0. Если это не так, он должен быть повторно встроен в composer.json для A.

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

Перевод с английского официальной документации Composer:
https://getcomposer.org/doc/articles/aliases.md

Самый честный хостинг за 20+ лет существования Лунной Базы

Задумываешься о том, чтобы поднять свой сайт в Интернете? Уже пора подумать о том, какой хостинг выбрать?

Лунная База хостится 20+ лет на firstDVS. При этом, мыслей о том, чтобы перебраться на другой хостинг не было. (Но, при этом есть опыт работы с другими вариантами.)

Бывали с firstDVS разные ситуации, но, они бывают на всех хостингах. Единственное, что тут важно понять, - это то, что никто ничего тебе не будет впаривать... Но, и работать за тебя тоже никто не станет. Если в саппорт ответили: «Читайте по ссылке и разбирайтесь сами...» или вообще «Обратитесь за помощью к специалисту», - это повод углубить свои знания в области сайтостроения, а не бежать к тем, что пообещают: «Мы всё чиним и всё делаем за своих клиентов абсолютно бесплатно!» Никто никогда ничего ни за кого "по доброте душевной" не делал, не делает и не будет делать!

Старт! Горячий старт на просторы интернета
Старт! Горячий старт на просторы интернета
Старт! Меню