Что такое composer и как им пользоваться. Что такое 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 библиотек, который облегчает установку, обновление и поддержку различных библиотек в вашем проекте.Программисту для комфортной работы нужна инфраструктура (это я вам точно говорю:-). Это и удобное кресло, мощная машина с двумя мониторами, и совеременная IDE, средства работы с базами данных, инструменты отладки. Но кроме того важна инфраструктура разработки самого проекта.

Возьмём к примеру Ruby. Этот язык, блин, ну просто законодатель мод в сфере веб-дева. Там и удобные инструменты скаффолдинга (ну в ZF это тоже есть), и такие штуки, как rake для выполнения задач. Я уж не говорю про миграции, юнит-тесты со всяческими mock-объектами. Когда я кодил на Ruby ощущение было сродни тому, что сидишь в комфортабельном кресле в бизнес-классе в самолете и единственной твоей проблемой является выбор напитка под настроение.

Шучу-шучу. Не всё так радужно в Ruby Есть куча кривых гемов, разработчики иногда выпускают такооое чудо, что мама не горюй. Я уж молчу про низкоуровневое шаманство, когда надо сделать что-то типа распределённой или многопоточной системы. Но речь в посте будет не об этом. А о том, что в Ruby есть такая штук, как RubyGems.

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

Что умеет Composer

Итак, краткий обзор фич. Их всего две: управление пакетами и автозагрузка классов. Надо сказать, что без composer обе эти задачи отнимали достаточно много времени. Интернет до сих пор пестрит статьями в стиле «как связать ZF 1.x и Doctrine 2» или «как установить Doctrine 2 ODM и Doctrine 1 ORM». Извращение, скажет вы. Я спеуиально утрировал, но согласитесь, приходится довольно сильно заморачиваться чтобы скрестить некоторые фреймворки или библиотеки. С выходом Composer ситуация поменялась.

Отдельное спасибо надо сказать за человеческую автозагрузку. Ух сколько времени я когда-то потратил на интеграцию Zend_Loader_Autoloader и Doctrine/ClassLoader. Теперь это в прошлом. Садимся в кресло

Пример composer.json

Вот пример файла с описанием зависимостей из одного проекта.

{ "require": { "doctrine/common": "2.3.0", "doctrine/migrations": "dev-master", "doctrine/dbal": "2.3.0", "doctrine/orm": "2.3.0", "doctrine/mongodb": "1.0.x-dev", "doctrine/mongodb-odm": "1.0.x-dev", "simukti/zf1": "1.12.0", "zendframework/zendframework": "2.0.3" }, "autoload": { "psr-0": { "ZendExtra": "vendor/netandreus/zend-extra/lib/", "DoctrineExtra" : "vendor/netandreus/doctrine-extra/lib/", "MyProject": "vendor/myvendor/myproject/lib/", "Hydrators": "misc/cache/", "": "app/default/models/" } }

Итак, давайте пройдёмся построчно. В блоке require мы описываем название пакетов в виде vendorName/packageName и минимально необходимые версии для нашего проекта. Потом они будут сами скачиваться и устанавливаться в папку vendor. Как видите Доктрина например раскукожилась сразу в несколько пакетов. Кстати миграции в отдельный пакет выделились совсем недавно, так что следите за новостями проекта. Товарищу simukti выражаю огромную благодарность, за то что он портировал все последние версии ZF 1.x в composer. Когда мне в своё время он понадобился, я начал это делать… да так и не успел в связи с другими задачами. Сейчас же в рамках одного проекта у нас есть возможность использовать компоненты Doctrine 2 ODM + ORM + ZF 1.x + ZF 2.x. Сумасшедший винигрет, но нам он нужен. Т.к. мы потихоньку мигрируем с MySQL (да простит меня Michail Widenius) на MongoDB. Основной костяк — на ZF1, ну а ZF2 — тоже не из праздного любопытсята /* интрига */ .

Теперь вторая часть конфига — require. Тут мы задаём классы (вернее их неймспейсы) и места их хранения, т.е. разрешаем пути для соответствующих неймспейсов. Обратите внимание на несколько моментов. Для гидраторов доктрины (если вы не знаете что это, то можете пропустить) указываем пути, т.к. при отсутствующем автозагрузчике доктрины она не может их найти. Последняя строка — местоположение помойки, где могут лежать классы с любыми неймспейсами. Основная особенность Composer в том, что такая помойка (к счастью) может быть только одна. А вот в нашем проекте классы require’ились откуда попало, поэтому пришлось провести так сказать garbage collection и свалить всё в одну кучу. Придётся конечно когда-нибудь и её разобрать, но теперь по крайней месте весь мусор в одном месте. Ну а ZendExtra и DoctrineExtra — этомои расширения, котоыре я частично описывал в своих постах.

Баги Composer

Ну куда же без багов. Самый пожалуй замечатенльный баг . Когда вы, уверенные, что у вас всё ок, делаете php composer.phar update, вас ждёт … разочарование. Пробелема в том, что composer не выкачивает исходники (вернее не обновляет их) если указана dev ветка, и исходники старше 6 месяцев. К сожалению в моём composer.json такими оказались пакеты с доктриной. Решение простое, перед тем, как делать update удаляем пакеты с доктриной.

Второй баг был в том, что в репозитарийх некоторых пакетов лежит файл.gitignore, который выкачивается при update/install. А если потом исходники проекта (вместе с этим пакетом) закоммитить, то они не дойдёт. Например в assembla, с которйо я работаю появляется некий пустой файл вместо папки с сорцами. При этом коммит и пуш проходит нормально, а траварищи жалуются, что к ним ничего не прилетает. Решение простое, после Update стираем наифг файлы.gitignore из изходников с пакетами.

Использовать или нет Composer?

Да! Как сказал кто-то, ваша библиотека — отстой, если в её корне не лежит файл composer.json Не ну серьезно, прошли времена php 4, phpclasses, кучи автозагрузчиков в стеке. Давайте перестанем плодить говнокод, будем соблюдать стандарты (ну хотя бы psr-0) и писать так сказать код с человеческим лицом. Я всецело за унификацию и стандартизацию! Enjoy!

Спасибо!

Если вам помогла статья, или вы хотите поддержать мои исследования и блог - вот лучший способ сделать это:

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

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

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

При создании Composer авторы черпали идеи и вдохновение из аналогичных проектов: npm для Node.js и Bundler для Ruby.

Изначально он был спроектирован и разработан двумя людьми 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 в своём проекте

Чтобы разобраться, как пользоваться Composer"ом, напишем маленький проектик на PHP: «Super Hello World». Поскольку мы не хотим изобретать велосипед и писать код «с нуля», возьмём готовые библиотеки и фреймворки.

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

микрофреймворк Silex
шаблонизатор Twig (доступен в виде Composer пакета на packagist.org),
наш собственный логер посещений SuperLogger , который я оформил в виде Composer-пакета и опубликовал на github
нашу старую, но любимую легаси-библиотеку superlib , которая состоит из мешанины классов без неймспейсов и функций без классов; библиотека опубликована на github, но не является оформленным 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, ...) и умеет скачивать и распаковывать библиотеки.

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

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

composer.json

Итак, мы готовы написать наш Super Hello World проект. И я его только что написал: http://github.com/pqr/superhelloworld . Код состоит из одного index.php файла в директории web и шаблона layout.twig в директории views.

Голова всему - это файл composer.json . Он должен быть в корне проекта, в нашем случае рядом с директориями web и view. В этом файле необходимо указать от каких библиотек зависит наш проект. Кроме того, если эти библиотеки не являются оформленными 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». Для mercurial репозитория аналогичная запись будет выглядеть как «dev-default». В качестве номера версии можно указать и более сложные правила, используя операторы сравнения. Кстати, если вы скачиваете код из удалённого репозитория, то Composer сканирует теги и имена веток в этом репозитории на предмет чего-то похожего на номера версий, например тег «v1.2.3» будет использован как указатель на версию 1.2.3.

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

Далее, подключим наш собственный пакет SuperLogger, который правильно оформлен, но опубликован не на packagist.org, а на github:
{ "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.*" } }

Инстукция autoload

Вернёмся к нашему проекту.
Описывая «pqr/superlib», мы добавили инструкцию autoload . В ней указан файл timer.php, в котором будущий автозагрузчик будет искать классы и указали файл с функциями lib_functions.php - он будет принудительно подключаться в начале autoload.php.

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

в корне лежит файл 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

php composer.phar install
Composer клонирует репозитории и распаковывает их на нужной версии в директорию vendor , которую он сам создаёт в корне проекта. После распаковки, в директории vendor мы найдём:

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

Остаётся только подключить autoload.php в начале файла web/index.php (require "../vendor/autoload.php") и все библиотеки и функции будут доступны!

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

В этом проекте мы использовали Composer с точки зрения потребителя библиотек. А как самому создать Composer пакет, чтобы любой другой человек смог им воспользоваться?

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

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

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

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

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

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

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

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

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

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

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

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

Ваш проект зависит от ряда библиотек
Некоторые из этих библиотек зависят от других библиотек.
Вы указываете какие библиотеки нужны непосредственно вам
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 читайте в следующих уроках.