Библиотеки

В этом разделе вы узнаете, как сделать вашу библиотеку устанавливаемой через Composer.

Каждый проект — это пакет

Как только у вас есть composer.json в директории, эта директория является пакетом. Когда вы добавляете require в проект, вы создаёте пакет, который зависит от других пакетов. Единственное отличие вашего проекта от библиотеки заключается в том, что ваш проект является пакетом без имени.

Для того, чтобы сделать этот пакет устанавливаемым, необходимо присвоить ему имя. Для этого добавьте свойство name в composer.json:

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

В этом случае имя проекта — acme/hello-world, где acme — имя поставщика. Указание имени поставщика является обязательным.

Примечание: Если вы не знаете, какое имя поставщика использовать, то имя вашего профиля на GitHub, как правило, подойдёт. Имена пакетов должны быть в нижнем регистре, а разделение слов должно осуществляться через дефис.

Версионирование библиотек

В подавляющем большинстве случаев вы будете поддерживать свою библиотеку, используя какую-либо систему управления версиями, например, git, svn, hg или fossil. В этих случаях Composer определяет версии из вашей системы контроля версий, и вы не должны указывать версию в вашем composer.json файле. (См. статью Версии, чтобы узнать, как Composer использует ветки и теги системы контроля версий для разрешения ограничений по версиям.)

Если вы поддерживаете пакеты вручную (то есть без системы контроля версий), вам необходимо явно указать версию, добавив значение version в ваш composer.json файл:

{
    "version": "1.0.0"
}

Примечание: Когда вы добавляете жёстко заданную версию в систему контроля версий, эта версия может конфликтовать с именами тегов. Composer не сможет определить номер версии.

Версионирование с помощью системы контроля версий

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

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

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

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

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

Публикация в системе контроля версий

После создания репозитория системы контроля версий (например, git), содержащего файл composer.json, ваша библиотека уже готова для установки через Composer. В данном примере мы опубликуем библиотеку acme/hello-world на GitHub под именем github.com/username/hello-world.

Теперь, чтобы протестировать установку пакета acme/hello-world, мы создадим новый проект локально. Мы назовём его acme/blog. Этот блог будет зависеть от acme/hello-world, который в свою очередь зависит от monolog/monolog. Мы можем достичь этого, создав новую директорию blog где-нибудь, содержащую composer.json:

{
    "name": "acme/blog",
    "require": {
        "acme/hello-world": "dev-master"
    }
}

Имя не требуется в этом случае, так как мы не хотим публиковать блог как библиотеку. Оно добавлено здесь, чтобы прояснить, какой composer.json описывается.

Теперь нам нужно указать блог-приложению, где найти зависимость hello-world. Мы делаем это, добавив спецификацию репозитория пакетов в composer.json блога:

{
    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/username/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}

Для получения более подробной информации о работе с репозиториями пакетов и о других типах репозиториев, см. Репозитории.

Всё. Теперь вы можете установить зависимости, выполнив команду Composer install!

Повторение: Любой репозиторий git/svn/hg/fossil, содержащий composer.json, может быть добавлен в ваш проект путём указания репозитория пакетов и объявления зависимости в поле require.

Публикация в Packagist

Итак, теперь вы можете публиковать пакеты. Но указание репозитория системы контроля версий каждый раз неудобно. Вы не хотите заставлять всех ваших пользователей делать это.

Другое, что вы, возможно, заметили, это то, что мы не указали репозиторий пакета для monolog/monolog. Как это работало? Ответ — Packagist.

Packagist — это основной репозиторий пакетов для Composer, и он включён по умолчанию. Всё, что опубликовано в Packagist, автоматически доступно через Composer. Поскольку Monolog находится в Packagist, мы можем зависеть от него, не указывая дополнительных репозиториев.

Если мы захотим поделиться hello-world со всем миром, мы также опубликуем его в Packagist.

Вы переходите на Packagist и нажимаете кнопку "Отправить". Это предложит вам зарегистрироваться, если вы ещё этого не сделали, а затем позволит вам отправить URL вашего репозитория системы контроля версий, после чего Packagist начнёт его сканирование. После завершения ваш пакет будет доступен всем!

← Основное использование | Командная строка →