Composer и пакетная революция в мире PHP

Мир PHP-разработки с давних времён славится хаотической практикой создания зависимых самописных неуниверсальных систем. И приверженцы остальных языков над ним смеялись. В последние годы, что действительно хорошо, он всё более масштабно переходит к другому, более осознанному будущему. Интересная для многих практика социального программирования с использованием публичных репозиториев привнесла идею обобщении полученных знаний.

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

Реализация структуры нового Yii2 переработана для работы с компонентами через Composer. По этому поводу мы его и рассмотрим. Но вначале немного удалимся в философию и психологию открытого программного обеспечения.

Новое программирование

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

Что же нужно для более широкого внедрения практики свободно распространяемых компонентов? Во многом это движение подкрепляется развитием цивилизованной публикации личных наработок в публичные репозитории, а также внедрением общих стандартов PSR.

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

Неужели нужно хранить принципиальный, граничащий с разумностью консерватизм и быть против заимствований в языках программирования? Гораздо полезнее собрать положительные черты изо всех языков друг в в друга, и этим сделать удобными и максимально эффективными все языки мира!

Вместо компонентов, сильно завязанных на реализацию конкретного фреймворка, в настоящее время наметилась практика создания кроссплатформенных, точнее сказать платформонезависимых компонентов, построенных по принципам SOLID. А именно движение к разработке на уровне интерфейсов и к избавлению классов от лишних зависимостей. Плюс появление пространств имён наконец избавило разработчиков от путаницы именования классов.

Раньше каждый фреймворк всё делал по-своему. Имел свои расширения для авторизации, почты, шаблонизации. Тысячи часов программисты тратили на написание своих компонентов и «обёрток» для адаптации готовой библиотеки под стандарты своей системы. Каждый фреймворк на своём официальном сайте имел список расширений, порой несовместимых с другими фреймворками. Но теперь, за счёт всеобщей договорённости об избавлении от лишних зависимостей и за счёт перехода всех крупных разработчиков на единые способы проектирования и написания кода, время неуместной самостоятельности проходит.

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

Миллионы репозиториев на GitHub и прочих подобных сервисах позволяют легко собрать нужный набор «запчастей» и использовать для написания своих приложений.

You don’t need a framework

Из чего состоит веб-приложение? А из чего фреймворк? Это, например, сборка из системы маршрутизации для «разруливания» адресов, ORM для работы с базой данных, контейнера для хранения компонентов, шаблонизатора, логгера и... подборки классов для работы с API разных систем, отправки электронной почты и дополнительных служебные компонентов.

Совсем недавно это приходилось либо программировать самому, либо не очень успешно искать в глубине блогов. Сейчас это уже другое время. Вам нужен ORM? Возьмите Doctrine или Propel. Нужен шаблонизатор? Возьмите Twig. Аналогично Monolog для ведения логов и SwiftMailer для почты. Нужен поиск? Загрузите себе компонент LuceneSearch от Zend Framework или найдите драйвер для Sphinx. А в качестве маршрутизатора можно взять тот-же компонент, который используется в Symfony Framework. И прочее, и прочее для работы с авторизациями социальных сетей, платёжными шлюзами...

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

Революция фреймворков

Набирающий сейчас популярность Laravel Framework уже один за одним обгоняет другие фреймворки. Сам он содержит мало кода, очень лёгкий внутри за счёт использования в своей работе пары десятков чужих публичных компонентов. Некоторые из них, кстати, мы уже перечислили. Похожая система компонентов издавна используется и в Symfony.

Если Yii1 это не использовал (в отличие от Symfony, Laravel и некоторых других), так как на момент его создания это было ещё не модно и многие вещи не поддерживались теми версиями языка PHP, то в новой версии Yii2 теперь встроены принципы работы с различными пакетами и соблюдены международные стандарты написания кода. А это значит, что прямо на наших глазах совершается переход, необходимый для любого серьёзного фреймворка. Совершился вход в новый объединённый союз. И на момент написания этих строк он уже совершён! Это важно. И скептицизм, разгорающийся в сети в момент каждой микрореволюции внутри любого фреймворка, здесь просто неуместен.

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

Что такое Composer

Развёртывание и разработка приложения происходит чаще всего так:

1. На реальном или виртуальном компьютере-сервере мы устанавливаем язык PHP. Но на «голом» интерпретаторе приложение требует дополнительных компонентов. Мы устанавливаем скомпилированные библиотеки, расширения через PEAR и Pecl, потом скачиваем из репозитория наш фреймворк. И после этого наш сайт начнёт работать. При этом мы, естественно, не включаем установленные библиотеки к файлам проекта в нашу систему контроля кода.

2. Теперь нам нужно найти и загрузить готовые компоненты. Мы заходим на GitHub или другие системы и клонируем оттуда эти библиотеки. Но при этом нужно быть аккуратным, так как они могут аналогично зависеть от других библиотек. Так что нам нужно изучить все компоненты и загрузить в нашу папку для расширений их полный комплект. Хорошим тоном было бы авторам компонентов указывать список зависимостей в файле Readme.

3. Все эти дополнительные компоненты для экономии места можно не хранить в системе контроля версий, так как для крупного проекта их размер может составить сотни мегабайт. Достаточно составить вручную и приложить их полный список. С указанием источника и рабочей версии. Для автоматизации процесса скачивания можно добавить bash-скрипт, который будет клонировать репозитории по этому списку.

4. В проекте теперь имеются несколько десятков сторонних расширений. Вместо ручного вызова include каждого класса можно сделать общий для всех автозагрузчик. Особенно если в классах используются пространства имён.

5. Со временем каждый компонент желательно обновлять. Если их десятки, то вручную это делать будет утомительно. Это тоже можно автоматизировать консольным скриптом. Также должна быть возможность указывать в списке конкретные ограничения по версиям, чтобы обновлять только минорные версии и не перескочить случайно «слишком сильно». Своеобразная настраиваемая и запускаемая вручную система автоматического обновления.

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

Именно этим (управлением зависимостями, централизованной загрузкой и обновлением компонентов) и занимаются пакетные менеджеры.

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

Так что мы теперь можем сформировать и дополнить некое понимание о его назначении. И даже можем теперь настроить список зависимостей для нашего проекта:

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

А по практическому применению можно ещё прочесть несколько материалов, включая упомянутую выше статью:

• Статья на Habrahabr;
• Официальный сайт Сomposer;
• Репозиторий компонентов Packagist;
• You don’t need a framework;
• UPD: Наш практикум по Git и Composer.

На этом пока всё. Пакетные менеджеры, надёюсь, стали понятнее. Если что-то не очень понятно или если есть чем дополнить, то напишите об этом в комментариях. Ну и не забывайте подписываться на рассылку, чтобы следить за сайтом. Это легко и полезно. Заранее спасибо!