Осваиваем Composer. Что такое composer Composer основы использования

Composer - менеджер зависимостей для PHP (Dependency Manager for PHP) или пакетный менеджер (зависимости это пакеты - логически законченные сторонние или собственные наработки, использующиеся в проекте).

Установить лучше глобально. Для OSX в терминале вводим

Curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer

Composer

Если всё правильно, то вы увидите список команд. Значит можно использовать composer.

1. Как создавать новый проект в composer?

Все зависимости composer хранит в файле composer.json, на вопрос "почему именно JSON?" разработчики Composer отвечают "Потому что. Просто примите это.".

Создать этот файл можно командой

Composer init (или php composer.phar init)

Композитор проведёт вас по нескольких шагам - название проекта, описание, лицензия. Для вас важен шаг, где composer просит указать пакет, который хотите установить. Он предложит поискать пакет (search for a package), где вы вводите, например, "yii" и поиск предлагает все пакеты для yii, имеющиеся на сайте packagist.org. Выбрав то, что вам надо composer создаст в папке вашего проекта файл composer.json, со всеми описанными зависимостями.

Теперь осталось их только установить командой:

Composer install

Все. Теперь в вашем проекте появилось все что вы хотели скачать.

2. Как создать проект из готового пакета через composer?

Делается это командой create-project ("Create new project from a package into given directory.") в папке, где хотите создать папку проекта.

Например возьмём пакет продвинутой заготовки для приложения на yii2 (https://packagist.org/packages/yiisoft/yii2-app-advanced). Значит этот пакет загрузили на packagist.org.

Composer create-project yiisoft/yii2-app-advanced yii2advanced 2.0.0-beta

yii2advanced - указываете название вашего проекта (папки на компьютере)
2.0.0-beta - версия (смотрим какие версии есть на packagist.org)

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

3. Обновлять пакет.

Командой

(Updates your dependencies to the latest version according to composer.json, and updates the composer.lock file.) - обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл — это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;

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

Composer - инструмент управления зависимостями для PHP. Вы можете указать от каких библиотек(пакетов) зависит ваш проект, и сomposer установит их за вас. Composer именно менеджер зависимостей, а не менеджер пакетов - это означает что библиотеки(пакеты) устанавливаются внутрь каждого проекта отдельно, а не глобально в систему.

Зачем нужен Composer?

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

Как работает Composer

Идея работы composer не нова, при его разработке брали идеи из пакетного менеджера для node.js - npm и Bundler - менеджер для управления зависимостями в ruby приложениях.

1. Ваш проект зависит от ряда библиотек
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы указываете какие библиотеки нужны непосредственно вам
4. Composer находит нужные библиотеки нужных вам версий и устанавливает их(в папку проекта), попутно устанавливая библиотеки необходимые для работы этих библиотек.

Где найти пакеты

По умолчанию пакеты скачиваются из официального репозитория packagist.org . Любой желающий может добавить туда пакет, либо скачать его.
Так-же можно скачивать пакеты напрямую из любого git, svn или mercurial репозитория, или это может быть просто zip архив доступный по любому адресу.
Устанавливаемая библиотека не обязательно должна быть оформлена в виде Composer-пакета.

Объявление зависимостей

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

{ "require": { "monolog/monolog": "1.2.*" } }

Мы просто указываем что наш проект требует установки пакета monolog/monolog любой версии начинающейся на 1.2 (например 1.2.1, 1.2.2 и т.д.)

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

Я писал о том, как создать свой автозагрузчик классов на php. Но автозагрузку классов для своего проекта можно сделать и с помощью менеджера зависимостей для PHP - Composer . Это особенно актуально, если проект достаточно большой и планируется использование Composer в качестве установки сторонних библиотек (зависимостей).

Для внесения своих данных в файлы автозагрузчика Composer, нужно внести изменения в файл composer.json , а если его еще нет в корне приложения – создать.
Создание осуществляется с помощью выполнения в командной строке, например в консоли OpenServera:
composer init
Перед этим нужно перейти в корневой каталог приложения.
Если Composer установлен не глобально, то вместо composer нужно писать php composer.pha r.

При этом будет предложено ввести данные по названию проекта, автору, предложено сразу вписать нужные зависимости. Эти данные не имеют отношения к автозагрузке классов. В принципе, можно вообще создать самому файл composer.json и разместить там в фигурных скобках только объект autoload :
{ "autoload": { "psr-4": { "Services\\": "services", "App\\": "app" } } }
Если же создавать данный файл с помощью команды composer init или использовать файл который уже имеется (если объект autoload отсутствует), то нужно поставить запятую после последнего элемента (но до последней фигурной скобки) и вписать блок autoload.

Согласно примера, для пространства имен начинающегося с Services должна подключаться папка с названием services , находящаяся в корне приложения. С App аналогично.
То есть, например, класс Services\Application должен находиться в папке services/Application.php , тогда Composer автоматически подключит его.

Раздел autoload может включать и другие подразделы: classmap, files.

Подраздел classmap отвечает за описание классов, именование которых не соответствует стандарту PSR-4 . То есть, в карте классов мы просто указываем где искать определенные классы. Например:
"classmap": [ "services/myserv/", "services/myserv/Ksl.php" ]
Тут первым элементом массива classmap указываем каталог в котором нужно искать требуемые файлы классов. При этом не уточняем название класса.
Вторым элементом показан пример указания конкретного файла класса, чтобы Composer не приходилось искать в папке services/myserv что-то еще. Конечно стоит прописывать или первый или второй вариант.

Подраздел files отвечает за описание файлов, которые нам необходимо подключать в самом начале исполнения приложения. Например это настройки приложения - config.php . Вместо того, чтобы подключать его в index.php :
require_once "../config.php"; можно указать, чтобы его подключил Composer:
"files": [ "config.php" ] в данном случае подключится файл config.php находящийся в корне приложения (там же где и файл composer.json куда это прописываем). Можно подключить любой файл указав путь к нему.

То есть структура блока autoload может включать разные компоненты:
"autoload": { "classmap": [ "services/myserv/Ksl.php" ], "psr-4": { "Services\\": "services", "liw\\": "" }, "files": [ "config.php" ] }
После вписывания нужного кода в объект autoload, сохраняем изменения и далее нужно выполнить обновление файлов автозагрузчика Composer. Если файл composer.json вы сами перед этим создавали, то файлов автозагрузчика еще и вовсе нет. Для того, чтобы они появились, выполните
composer install создастся папка vendor, а в ней папка composer с файлами автозагрузки. Там же будет файл autoload_psr4.php в котором перезаписаны наши правила поиска классов согласно стандарта psr-4 и аналогичные файлы для карты классов и файлов.

Если папка vendor с данными файлами уже была, а вам нужно изменить данные для подключения своих классов, то нужно выполнить команду:
composer dump-autoload -o которая обновит файлы автозагрузчика Composer и при этом не будут устанавливаться и обновляться зависимости (библиотеки прописанные в блоке require).
Используя после команды ключ «-o », что значит «optimize», классы соответствующие стандарту psr-4 и прописанные для данного объекта будут прописаны в карте классов, что ускорит их загрузку в дальнейшем.

Так же в папке vendor находится файл autoload.php , который нужно подключить для того, чтобы заработала автозагрузка. Обычно его подключают в «точке входа» файле index.php :
require_once "../vendor/autoload.php"; используя «../» сначала поднимаемся на один уровень выше (у меня index.php находится в каталоге public). Если у вас другая структура, например индексный файл находится в корне приложения, то нужно прописать соответствующий путь к данному файлу.

) - это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer - это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano , сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github .

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2 ). Список проектов использующих Composer можно посмотреть на сайте packagist.org - это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Что умеет Composer?

• Скачивать пакеты и их зависимости;
• по умолчанию, пакеты скачиваются из официального репозитория packagist.org. Любой человек может свободно добавить туда свой пакет, чтобы сделать его установку максимально лёгкой и удобной для всего мира;
• пакеты можно скачивать не только с packagist.org, но и из любого git, mercurial или svn репозитория;
• при скачивании пакетов с github.com или bitbucket.org не требуется установленной системы контроля версий (git или hg), Composer работает через API этих сайтов;
• git/hg/svn репозиторий с пакетом может находиться не только на одном из перечисленных выше сайтов, но в любом другом месте, например, в локальной сети предприятия или вообще на локальном жестком диске;
• кроме того, устанавливаемая библиотека не обязательно должна быть оформлена в виде Composer-пакета, вы можете сделать установку из любого git/hg/svn репозитория произвольной структуры;
• наконец, устанавливаемый пакет не обязательно должен быть git/hg/svn репозиторием, это может быть произвольный zip файл доступный по любому uri!
• все пакеты устанавливаются в текущую директорию (откуда была выполнена команда install), это позволяет иметь несколько различных версий библиотек при работе над разными проектами параллельно;
• команда update обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл - это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;
• после установки пакетов автоматически генерируется autoload.php, с помощью которого можно подключить установленные библиотеки в коде вашего проекта. При подготовке Composer-пакета рекомендуется использовать PSR-0 - стандарт расположения и именования php файлов, чтобы autoload смог их легко найти. В любом случае, автор пакета может описать правила, по которым autoload будет искать файлы тех или иных классов или неймспейсов. Если вы устанавливаете библиотеку, которая не оформлена как Composer-пакет (например, произвольный git репозиторий с github), то задача описания правил autoload ложится на ваши плечи. Так что никакой магии с генерируемым autoload.php нет - он умеет загружать всё (даже библиотеки с набором функций вне классов), главное, чтобы были описаны правила (автором библиотеки или вами).

Рабочий пример: используем Composer в своём проекте

Мы будем использовать cледующие библиотеки:

1. микрофреймворк Silex
2. шаблонизатор Twig (доступен в виде Composer пакета на packagist.org),
3. наш собственный логер посещений SuperLogger , который я оформил в виде Composer-пакета и опубликовал на github
4. нашу старую, но любимую легаси-библиотеку superlib , которая состоит из мешанины классов без неймспейсов и функций без классов; библиотека опубликована на github, но не является оформленным Composer-пакетом

Как мы это сделаем теперь: используем Composer - он сам скачает все библиотеки и сгенерирует для нас autoload.php. Кроме того, если мы захотим показать «Super Hello World» коллегам, достаточно будет опубликовать код нашего проекта на github (или ещё где-нибудь), не включая всех требуемых библиотек в репозиторий и не готовя длинной инструкции по их установке. Нашим коллегам достаточно будет скачать (склонировать) «Super Hello World» и выполнить команду
php composer.phar install
Composer распространяется в виде одного файла composer.phar (phar - это php-архив) - по сути это PHP скприт, который может принимать несколько команд (install, update, ...) и умеет скачивать и распаковывать библиотеки.

Кстати, немного о синтаксисе запуска.
Если вы работаете под Windows, то скорее всего вы будете писать что-то вроде
php C:\path\to\composer.phar install
Можно упростить себе жизнь, создав composer.bat и положив его в %PATH%.

В Linux и OS X можно настроить на исполнение команду типа
composer install

composer.json

Голова всему - это файл composer.json . Он должен быть в корне проекта, в нашем случае рядом с директориями web и view. В этом файле необходимо указать от каких библиотек зависит наш проект. Кроме того, если эти библиотеки не являются оформленными Composer-пакетами, то нужно указать некоторую дополнительную информацию об устанавливаемой библиотеке (например, описать правила автозагрузки классов и функций для autoload.php).

Composer.json, как вы догадались, имеет формат данных JSON. На вопрос "почему именно JSON? " разработчики Composer отвечают "Потому что. Просто примите это. ".

Нам нужно описать один js-объект, в котором будут находиться все инструкции. Первая и самая главная инструкция: require .

Подключаем пакеты с сайта packagist.org

Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки . Названием поставщика зачастую является ник автора или имя компании. Иногда, название поставщика совпадает с именем самой библиотеки или фреймворка.

Для каждого пакета обязательно нужно указать номер версии. Это может быть бранч в репозитории, например, «dev-master» - приставка dev сигнализирует, что это имя бранча, а сам бранч соответсвенно называется «master». Для mercurial репозитория аналогичная запись будет выглядеть как «dev-default». В качестве номера версии можно указать и более сложные правила, используя операторы сравнения. Кстати, если вы скачиваете код из удалённого репозитория, то Composer сканирует теги и имена веток в этом репозитории на предмет чего-то похожего на номера версий, например тег «v1.2.3» будет использован как указатель на версию 1.2.3.

Подключаем на собственный Compsoer-пакет

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

Подключаем простой zip файл

Инстукция autoload

Итак, наш проект состоит из:

• в корне лежит файл composer.json;
• в корне находятся директории web и views;
• внутри директории web лежит файл с «бизнес-логикой» нашего приложения: index.php;
• внутри директории views лежит файл шаблона layout.twig;
• дополнительно, в папку web я положил.htaccess (для apache) и web.config (для IIS 7.5) с правилами mod_rewrite/url rewriter - непосредсвенно к настройке Composer они отношения не имеют.

Запускаем composer install

• файл autoload.php
• служебные директории.composer и composer
• pimple - пакет, который подтянулся вместе с микрофреймворком Silex
• silex - сам микрофреймворк, его мы явным образом затребовали при описании зависимостей
• symfony - некоторые компоненты из Symfony 2, которые требуются для работы Silex
• twig - шаблонизатор, который мы также явно запросили
• mycompany - внутри этой директории будет находиться репозиторий superlogger скаченный с github
• pqr - внутри этой директории будет находиться репозиторий superlib, также скаченный с github

Как создать собственный Composer пакет?

На самом деле, один из таких пакетов я создал, когда подготавливал примеры для этой статьи. В корне репозитория superlogger лежит файл composer.json похожей структуры, который описывает сам пакет и его зависимости (в случае с superlogger зависимостей нет). Другие примеры: репозитории silex и twig, которые скачались в папку vendor - все они имеют файл composer.json в корне - смотрите, изучайте!

И, конечно, не забывайте про документацию на официальном сайте getcomposer.org/doc/ .
Эту тему я оставлю вам для самостоятельной проработки.

Подведём итоги

Самое время попробовать!

1. Скачате Composer (getcomposer.org/download/)
2. Скачате superhelloworld (git clone git://github.com/pqr/superhelloworld.git)
3. Установите зависимости (cd superhelloworld && php composer.phar install)
4. Изучите появившуюся папку vendor и сгенерированный autoload.php
5. Используте Composer в своих проектах
   …
6. PROFIT!!!

На добавку пара ссылок

У меня знакомство с Composer началось с того, что мы начали внедрять проект на фреймворке YII 2. YII 2 еще был в стадии alpha-версии и, кроме того, что он представлял собой мало документированный инструмент, так еще и тянул за собой кучу не знакомых технологий. Что нужно для того, чтобы начать работать с YII 2 я упомянул .

Вот, как проводилось это наше знакомство, где мой коллега рассказывает о том, как мы можем применить Composer в нашем проекте:

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

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

Что умеет Composer?

• Скачивать пакеты и их зависимости;
• по умолчанию, пакеты скачиваются из официального репозитория packagist.org. Любой человек может свободно добавить туда свой пакет, чтобы сделать его установку максимально лёгкой и удобной для всего мира;
• пакеты можно скачивать не только с packagist.org, но и из любого git, mercurial или svn репозитория;
• при скачивании пакетов с github.com или bitbucket.org не требуется установленной системы контроля версий (git или hg), Composer работает через API этих сайтов;
• git/hg/svn репозиторий с пакетом может находиться не только на одном из перечисленных выше сайтов, но в любом другом месте, например, в локальной сети предприятия или вообще на локальном жестком диске;
• кроме того, устанавливаемая библиотека не обязательно должна быть оформлена в виде Composer-пакета, вы можете сделать установку из любого git/hg/svn репозитория произвольной структуры;
• наконец, устанавливаемый пакет не обязательно должен быть git/hg/svn репозиторием, это может быть произвольный zip файл доступный по любому uri!
• все пакеты устанавливаются в текущую директорию (откуда была выполнена команда install), это позволяет иметь несколько различных версий библиотек при работе над разными проектами параллельно;
• команда update обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл — это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;
• после установки пакетов автоматически генерируется autoload.php, с помощью которого можно подключить установленные библиотеки в коде вашего проекта. При подготовке Composer-пакета рекомендуется использовать PSR-0 — стандарт расположения и именования php файлов, чтобы autoload смог их легко найти. В любом случае, автор пакета может описать правила, по которым autoload будет искать файлы тех или иных классов или неймспейсов. Если вы устанавливаете библиотеку, которая не оформлена как Composer-пакет (например, произвольный git репозиторий с github), то задача описания правил autoload ложится на ваши плечи. Так что никакой магии с генерируемым autoload.php нет — он умеет загружать всё (даже библиотеки с набором функций вне классов), главное, чтобы были описаны правила (автором библиотеки или вами).

Как мы делали раньше, когда не было Composer: скачивали нужные нам фреймворки и библиотеки, думали куда их распаковать, писали в проекте кучу require (или require_once для надёжности).

Как мы поступаем теперь, когда у нас есть Composer: он сам скачает все библиотеки и сгенерирует для нас autoload.php. Кроме того, если мы захотим показать «Super Hello World» коллегам, достаточно будет опубликовать код нашего проекта на github (или ещё где-нибудь), не включая всех требуемых библиотек в репозиторий и не готовя длинной инструкции по их установке. Нашим коллегам достаточно будет скачать (склонировать) «Super Hello World» и выполнить команду

php composer.phar install

Composer распространяется в виде одного файла composer.phar (phar - это php-архив) - по сути это PHP скприт, который может принимать несколько команд (install, update, …) и умеет скачивать и распаковывать библиотеки.

При настройке своего проекта и установки зависимостей для него, нужно помнить, что голова всему - это файл composer.json. Он должен быть в корне проекта, в нашем случае рядом с директориями web и view (YII 2). В этом файле необходимо указать от каких библиотек зависит наш проект. Кроме того, если эти библиотеки не являются оформленными Composer-пакетами, то нужно указать некоторую дополнительную информацию об устанавливаемой библиотеке (например, описать правила автозагрузки классов и функций для autoload.php).

composer.json, имеет формат данных JSON. На вопрос «почему именно JSON?» разработчики Composer отвечают «Потому что. Просто примите это.».

Нам нужно описать один js-объект, в котором будут находиться все инструкции. Первая и самая главная инструкция: require.
Подключаем пакеты с сайта packagist.org:

{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev" } }

Здесь я описал зависимость проекта от PHP версии 5.3.0 и выше, от silex (микрофреймворк) и от twig (шаблонизатор). Silex и Twig доступны в виде Composer-пакетов на сайте packagist.org, поэтому дополнительных настроек не требуют. Замечу, что Silex в свою очередь зависит ещё от нескольких пакетов - все они будут скачены и установлены автоматически.

Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки. Названием поставщика зачастую является ник автора или имя компании. Иногда, название поставщика совпадает с именем самой библиотеки или фреймворка.

Для каждого пакета обязательно нужно указать номер версии. Это может быть бранч в репозитории, например, «dev-master» - приставка dev сигнализирует, что это имя бранча, а сам бранч соответсвенно называется «master». Кстати, если вы скачиваете код из удалённого репозитория, то Composer сканирует теги и имена веток в этом репозитории на предмет чего-то похожего на номера версий, например тег «v1.2.3» будет использован как указатель на версию 1.2.3.

Подключаем наш собственный Composer-пакет

{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" } ] }

Чтобы Composer знал где искать пакет «mycompany/superlogger», мы добавили массив repositories со ссылкой на соотвествующий github репозиторий. Обратим внимание, что записи в массиве repositories напрямую никак не связаны с блоком require - между пакетами и репозиториями не указано соответствие. На сколько я понял, Composer ищет все требуемые пакеты во всех указанных репозиториях (в т.ч. на сайте packagist.org) и скачивает найденные совпадения по каким-то внутренним приоритетам. Более глубоко я в этом моменте ещё не разбирался, поправьте меня, если кто-то знает детали.

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

Теперь подключим нашу легаси-библиотеку superlib, которая лежит на github, но не является оформленным Composer-пакетом, т.к. она очень старая.

{ "require":{ "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master", "pqr/superlib":"1.2.3" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" }, { "type":"package", "package":{ "name":"pqr/superlib", "version":"1.2.3", "source":{ "type":"git", "url":"http://github.com/pqr/superlib", "reference":"master" }, "autoload":{ "classmap":["timer.php"], "files":["lib_functions.php"] } } } ] }

В массив repositories добавился объект, который целиком описывает пакет pqr/superlib. По сути, это то описание, которое должен был бы сделать автор библиотеки и положить его внутри своего репозитория. Но по условиям задачи, superlib не является оформленным Composer-пакетом, поэтому нам пришлось создать его описание в рамках Super Hello World проекта. Аналогичным образом можно подключить любую другую библиотеку, в т.ч. простой zip файл.

Подключаем простой zip файл

Например, вот как могло бы выглядеть описание зависимости от шаблонизатора Smarty, распространяемого в виде zip файла с исходниками в svn:

{ "repositories":[ { "type":"package", "package":{ "name":"smarty/smarty", "version":"3.1.7", "dist":{ "url":"http://www.smarty.net/files/Smarty-3.1.7.zip", "type":"zip" }, "source":{ "url":"http://smarty-php.googlecode.com/svn/", "type":"svn", "reference":"tags/Smarty_3_1_7/distribution/" } } } ], "require":{ "smarty/smarty":"3.1.*" } }