Composer & Packagist 101
Привет, Хабр! Сегодня я хотел бы поговорить с вами о знакомых опытным PHP-девелоперам, но загадочных для новичков, штуках — Composer и Packagist. Не сомневаюсь, что для многих здесь текст не станет откровением. Материал для тех, кому с описанным ниже только предстоит столкнуться.
Вы — PHP-разработчик, и вам нужен хороший менеджер зависимостей — как npm или Bundler? Вам надоело мучаться с pear? И вы не хотите вручную качать библиотеки с сайтов и обновлять все зависимости? Тогда самое время познакомиться с Composer и Packagist.
Основы
Начнем с объяснения, что такое Composer, а чуть позже поговорим и про Packagist. Composer — изначально менеджер зависимостей для PHP на уровне проекта. Это значит, что теперь нам не нужно мучиться с когда-то популярным pear, потому что для каждого проекта нужны свои версии библиотек и прочего. Теперь с помощью Composer все зависимости будут установлены в папку vendor в корне вашего проекта, и проекты не будут конфликтовать. Каждому проекту будет доступен свой набор установленных зависимостей.
Также в composer.json можно задать секцию scripts. Если грамотно ее использовать, можно получить легкий деплой-менеджер. Но изучение этой секции оставляю вам в качестве домашнего задания :).
Как это работает? Нужно просто создать файл composer.json в корне проекта и заполнить его согласно документации. Требуемый минимум в этом файле — набор зависимостей. По сути, это просто json-объект, ключ в котором — название нужного пакета, а значение — нужная для проекта версия. Для указания версий используется semver. Например, если для проекта нужны PHP минимум версии 5.4 и библиотека для логгирования monolog 1.9.*, нужно указать следующий объект require.
Дальше просто нужно в командной строке выполнить команду composer update, и все новые зависимости будут подгружены в папку vendor, и вы сможете их использовать. Да, целиком PHP Composer не подтянет, но проверит, чтобы установленный на машине PHP был нужной версии. А если речь идет о библиотеках, Composer скачает пакет подходящей версии в папку vendor.
Представьте ситуацию: мы наконец-то внедрили в свой проект Composer, вовсю его используем, в общем, мы — молодцы! Но в какой-то момент приходим к ситуации, когда и у разработчиков и на сервере стоят разные версии библиотек. Как быть? Для этого composer рядом с composer.json создает файл composer.lock. В него после команды composer update записывается точная информация о версиях, которые установлены. Его нужно закоммитить в систему контроля версий, и таким образом все разработчики, а также на сервере можно просто выполнить команду composer install, и будут установлены все библиотеки точно таких версий, которые описаны в этом файле.
Пишем свой пакет
Любой желающий разработчик имеет право создать свой composer пакет и выложить в Open Source. Этот процесс я и хочу описать дальше.
Composer пакет по сути — это набор файлов, которые можно подключить в любой проект. Всё это можно отсортировать по папкам, как Вам только захочется. Главное, настроить автозагрузку composer. Какая же структура Composer пакета? Обязательным файлом для любого пакета является composer.json. Это файл в котором хранится вся информация про данный пакет: название, описание, список зависимостей, тип лицензии, и так далее. Вот пример composer.json простого пакета.
Name — имя пакета (формат vendor/name).
Type — тип пакета, данный пакет — библиотека
Description — описание пакета.
License — тип лицензии.
Require — список зависимостей данного пакета. Для него требуется версия PHP не менее 5.4.0 и пакет illuminate/support. Все версии описываются по semver.
Autoload — настройки автозагрузки. В данном случае указано, что неймспейс Dataart\Package начинается в папке src. Т. е. у всех файлов, которые лежат в папке src, должен быть неймспейс Dataart\Package. Если, например, хотите создать класс User и сохранить файл класса в папке Models, неймспейс класса User должен быть Dataart\Package\Models.
В папке src хранятся все нужные для работы пакета файлы. Рекомендуется рядом с папкой src сделать папку tests, и покрыть библиотеку тестами. Далее вся папка, в которой лежит composer.json, должна быть закоммичена на Github. Можно на Bitbucket, но все используют именно Github.
Также composer имеет некоторое количество консольных команд, которые призваны ускорить работу с ним.
запустит для вас интерактивную инициализацию composer проекта и, задав несколько основных вопросов, сгенерирует composer.json-файл.
install
считывает composer.json, разрешает зависимости и устанавливает их в папку vendor. Если в папке есть файл composer.lock, будут использованы точные версии, указанные в файле. Это даёт возможность всем разработчикам иметь одинаковые версии всех библиотек.
update
используется, чтобы получить новые версии пакетов, тем самым обновить composer.lock. Также используется, если добавились новые зависимости. Может использоваться также с параметрами. composer update vendor/package1 vendor/package2 обновит только два пакета. Также можно обновить все пакеты одного вендора командой composer update vendor/*
require
добавляет новые зависимости из командой строки. Например, composer require vendor/package:2.* vendor/package2:dev-master. Если не указать версию, composer автоматически подтянет последнюю стабильную версию.
remove
точная противоположность require.
dump-autoload
обновить autoloader, если появились новые классы или правила автолоадинга.
К командам install, update и dump-autoload можно добавить ключ —optimize-autoloader (-o), чтобы конвертировать правила автозагрузки psr-0/4 в «карту классов», чтобы ускорить автозагрузку. Рекомендуется для production окружения.
Open Source It
Закоммитили? Круто, но composer всё равно почему-то не находит пакет и не может его подтянуть для другого проекта. Как быть?
Да, можно указывать конкретные адреса svn/git репозиториев в composer.json, но это неудобно. Намного удобнее иметь какой-то центральный пункт, где есть соответствия пакетов с их адресами репозиториев. Это Packagist.
Он используется для публикации composer пакетов. Опубликовать свой пакет туда очень легко. Достаточно зарегистрироваться на сервисе (или используя Github аккаунт через oAuth2), далее перейти по ссылке Submit Package, указать URL репозитория, а Packagist всё остальное сам подтянет и периодически будет проверять репозиторий на наличие новых версий.
Как происходит версионирование? Версионировать надо согласно системе semver. А указывать версии пакетов, используя тэги в системе контроля версий. Всё очень просто!
Создавайте свои пакеты, публикуйте их и становитесь полноценным участником Open Source сообщества.
21 совет по эффективному использованию Composer
Совет № 1: читайте документацию
Я серьёзно. Документация у него замечательная, и несколько часов чтения сэкономят вам кучу времени в долгосрочной перспективе. Вы удивитесь, как много всего умеет делать Composer.
Совет № 2: различайте проект и библиотеку
Важно знать, что вы создаёте — проект или библиотеку. Каждый из вариантов требует своего набора методик.
Проект обычно представляет собой приложение, зависящее от нескольких библиотек. Обычно он не используется несколько раз (никакому другому проекту он не понадобится в качестве зависимости). Характерные примеры: сайт интернет-магазина, система поддержки пользователей и т. д.
Дальше в советах я буду переключаться между библиотекой и проектом.
Совет № 3: используйте для приложения конкретные версии зависимостей
Обновляйте зависимости обдуманно, а не импульсивно. Подробнее об этом мы поговорим в одном из следующих советов.
Возможно, это кажется чрезмерным, но внимание к версиям зависимостей не даст вашим коллегам неосмотрительно обновить все зависимости при добавлении в проект новой библиотеки (которую вы могли пропустить при ревизии кода).
Совет № 4: для зависимостей библиотек используйте диапазоны версий
Если вы делаете библиотеку, то определяйте самый возможный диапазон версий. Если создаёте библиотеку, использующую библиотеку symfony/yaml для YAML-разбора, то запрашивайте её так: «symfony/yaml»: «^3.0 || ^4.0»
Тогда ваша библиотека сможет использовать symfony/yaml из любых версий Symfony с 3.x по 4.x. Это важно, поскольку данное ограничение распространяется и на приложение, которое обращается к вашей библиотеке.
Если есть две библиотеки с конфликтующими требованиями (одной, к примеру, нужна
3.2.0), то будет сбой при установке.
Совет № 5: в приложениях нужно коммитить composer.lock в Git
Если вы создаёте проект, то нужно коммитить composer.lock в Git. Тогда все — вы, ваши коллеги, ваш CI-сервер и рабочий сервер — будут использовать приложение с одинаковыми версиями зависимостей.
На первый взгляд этот совет кажется излишним. Вы уже выбрали конкретную версию, как в совете № 3. Но ещё существуют зависимости ваших зависимостей, которые не связаны этими ограничениями (например, symfony/console зависит от symfony/polyfill-mbstring ). Так что без коммита composer.lock вы не получите такой же набор зависимостей.
Если вы создаёте библиотеку (назовём её acme/my-library ), то не нужно коммитить файл composer.lock. Это никак не влияет на проекты, использующие вашу библиотеку.
Если хотите быть уверены в совместимости библиотеки с разными версиями её зависимостей, читайте следующий совет!
Совет № 7: запускайте сборки Travis CI с разными версиями зависимостей
Совет относится только к библиотекам (потому что для приложений вы используете конкретные версии).
Если вы собираете open-source библиотеку, то, вероятно, запускаете сборки с помощью Travis CI. По умолчанию Composer устанавливает последние возможные версии зависимостей, допускаемые ограничениями в composer.json. Это означает, что для ограничения зависимости ^3.0 || ^4.0 сборка всегда будет использовать последнюю версию релиза v4. И поскольку версия 3.0 никогда не тестировалась, библиотека может оказаться несовместимой с ней, что опечалит пользователей.
Можете посмотреть её в работе на примере моей библиотеки mhujer/fio-api-php и матричной сборки Travis CI.
Хотя это решение позволит выловить большинство несовместимостей, помните, что между старшей и младшей версиями существует много комбинаций зависимостей. И они могут быть несовместимы.
Совет № 8: сортируйте пакеты в require и require-dev по имени
Хорошая привычка — держать пакеты в require и require-dev отсортированными по имени. Это поможет пресекать ненужные конфликты слияния при перебазировании ветки. Потому что если вы в двух ветках добавляете пакет в конце списка, то конфликты слияния будут возникать каждый раз.
Вручную это делать нудно, так что лучше сконфигурировать в composer.json:
Когда вы в следующий раз затребуете ( require ) новый пакет, он будет добавлен в правильное место (не в конец).
Совет № 9: не пытайтесь объединять composer.lock при перебазировании или слиянии
Если вы добавили в composer.json новую зависимость (и composer.lock) и перед слиянием ветки в мастер была добавлена другая зависимость, вам нужно перебазировать ветку. И вы получите в composer.lock конфликт слияния.
Никогда не пытайтесь разрешить его вручную, потому что файл composer.lock содержит хеш зависимостей, определённых в composer.json. Так что, если даже вы разрешите конфликт, получится некорректный lock-файл.
Можете решить проблему с помощью кратковременных веток фич (feature branches), как предлагается в Trunk Based Development (это нужно делать в любом случае). Если у вас есть правильно объединённая краткосрочная ветка, риск конфликта слияния в composer.lock минимален. Даже можете создать ветку только для добавления зависимости и сразу объединить её.
Совет № 10: помните о разнице между require и require-dev
Пакеты, необходимые для разработки приложения или библиотеки, должны быть определены в require-dev (например, PHPUnit, PHP_CodeSniffer, PHPStan).
Совет № 11: обновляйте зависимости безопасно
Полагаю, вы согласны с утверждением, что зависимости нужно регулярно обновлять. И я советую делать обновление зависимостей прозрачно и продуманно, а не по мере какой-то другой работы. Если вы что-то рефакторите и в то же время обновляете какие-то библиотеки, то не сможете сказать, чем сломано приложение, рефакторингом или обновлением.
Для каждой устаревшей зависимости придерживайтесь плана:
Или можете использовать шаблон для обновления всех зависимостей из определённого пространства имён:
Знаю, всё это выглядит утомительным, но наверняка вы обновляете зависимости по случаю, так что лучше перестраховаться.
Можно лишь в одном облегчить себе работу: разом обновлять все зависимости require-dev (если они не требуют изменений в коде, иначе предлагаю использовать отдельные ветки для упрощения ревизии кода).
Совет № 12: можете определять в composer.json другие типы зависимостей
Помимо определения библиотек в качестве зависимостей, вы также можете определять там и другие вещи.
Например, какие версии PHP поддерживает приложение/библиотека:
Или какие расширения необходимы приложению/библиотеке. Это очень полезно, если пытаешься поместить приложение в контейнер или если твой новый коллега впервые настраивает приложение.
Используйте * для версий расширений, потому что они могут быть несогласованными.
Совет № 13: проверяйте composer.json в ходе CI-сборки
composer.json и composer.lock должны быть всегда синхронизированы. Поэтому целесообразно автоматически проверять их синхронизированность. Просто добавьте этот механизм в свой скрипт сборки:
Совет № 14: используйте Composer-плагин в PHPStorm
Существует composer.json-плагин для PHPStorm. Он добавляет автокомплит и ряд проверок при ручном изменении composer.json.
Если вы используете другую IDE (или только редактор кода), можете настроить проверку его JSON-схемы.
Совет № 15: определяйте в composer.json рабочие версии PHP
Если вы, как и я, любите иногда локально запускать предварительные релизы версий PHP, то рискуете обновить зависимости до версий, не работающих в продакшене. Сейчас я использую PHP 7.2.0, т. е. могу устанавливать библиотеки, которые не будут работать на 7.1. А поскольку продакшен использует 7.1, установка завершится сбоем.
Но переживать не нужно, есть лёгкое решение. Просто определите рабочие версии PHP в разделе config файла composer.json:
Совет № 16: используйте приватные пакеты из Gitlab
Рекомендую выбирать vcs в качестве типа репозитория, и Composer должен определить правильный способ извлечения пакетов. Например, если вы добавляете форк с GitHub, он будет использовать свой API для скачивания zip-файла вместо клонирования всего репозитория.
Но с приватной установкой с Gitlab несколько сложнее. Если вы используете vcs в качестве типа репозитория, Composer определит его как Gitlab-установку и попытается скачать пакет через API. Для этого потребуется API-ключ. Я не хотел его настраивать, поэтому сделал так (моя система использует SSH для клонирования).
Сначала определил репозиторий типа git :
А затем использовал пакет, как это обычно делается:
Совет № 17: как временно использовать ветку из форка с исправлением бага
Если вы нашли баг в публичной библиотеке и исправили его в своём форке на GitHub, то вам нужно установить библиотеку из своего репозитория, а не из официального (пока исправление не будет объединено и не появится исправленный релиз).
Это легко можно сделать с помощью inline aliasing:
Можете локально протестировать своё исправление, прежде чем загружать его, используя path в качестве типа репозитория.
Совет № 18: установите prestissimo для ускорения установки пакетов
Composer-плагин hirak/prestissimo ускоряет установку зависимостей посредством параллельного скачивания.
Достаточно установить его один раз глобально, и он будет автоматически работать для всех проектов:
composer global require hirak/prestissimo
Совет № 19: если не уверены, протестируйте свои версионные ограничения
Написание корректных версионных ограничений иногда становится непростой задачей после прочтения документации.
Совет № 20: используйте в продакшене авторитарную карту классов (class map)
Сгенерируйте в продакшене авторитарную карту классов. Это ускорит загрузку классов благодаря включению в карту всего необходимого и пропуску любых проверок файловой системы.
Можете делать это в рамках вашей рабочей сборки:
Совет № 21: для тестирования сконфигурируйте autoload-dev
Вам не нужно включать тестовые файлы в рабочую карту классов (из-за размера файла и потребления памяти). Это можно сделать с помощью конфигурирования autoload-dev (аналогично autoload ):
PHP Composer: фиксим зависимости без боли
Многие из вас наверняка сталкивались с ситуацией, когда в библиотеке или фреймворке, который вы используете, есть баг или нет необходимой функциональности. Предположим, вы даже не поленились и сформировали pull request. Но примут его далеко не сразу, а следующий релиз продукта вообще может произойти через год.
Что же делать, если исправление вам срочно нужно катить в прод? Напрашивается очевидное решение — использовать форк библиотеки или фреймворка. Однако с форками не всё просто. Использовать наследования для переопределения функциональности, которую нужно изменить, не всегда возможно и часто требует больших изменений. На помощь приходят плагины для Composer, которые умеют патчить зависимости.
В этой статье я расскажу подробнее о том, почему форки — это неудобно, а также рассмотрю два плагина для Composer для патчинга зависимостей: чем они отличаются, как ими пользоваться и в чём их преимущества. Если вы сталкивались подобными проблемами или вам просто интересно, добро пожаловать под кат.
Проблему удобнее всего рассматривать на примере. Давайте предположим, что мы хотим что-то изменить в библиотеке PHP Code Coverage, которая используется во фреймворке тестирования PHPUnit для измерения уровня покрытия кода тестами. Допустим, мы хотим исправить в версии 7.0.8 как-то так (файл myFix.patch ):
Создадим нашу библиотеку-пример. Пусть это будет php-composer-patches-example. Детали здесь не очень важны, но на случай если вы решите посмотреть, что из себя представляет библиотека, я привожу консольный вывод под спойлером.
Что не так с форком зависимости
Давайте посмотрим, как происходит форк зависимости. Попробуем форкнуть PHP Code Coverage.
Что с этим делать? Есть четыре варианта:
Второй и четвертый варианты кажутся меньшим из зол. По количеству действий они примерно одинаковые, в этой статье рассмотрим только один — четвертый. Создадим тег альфа-релиза:
Прошу обратить внимание на то, что php-composer-patches-example подключается как репозиторий, поскольку этот репозиторий является лишь примером и потому не был добавлен в Packagist. В вашем случае этот шаг, скорее всего, можно пропустить.
Подведём итоги использования форков.
Плюсы этого подхода:
Минусы этого подхода:
Я думаю, вы уже поняли, что форк зависимости не является такой уж хорошей идеей.
Использование cweagans/composer-patches
В очередной раз испытывая боль и страдания от использования форков, я наткнулся на cweagans/composer-patches в PHP-Дайджесте № 101 (кстати, у pronskiy полезный блог, рекомендую подписаться). Это плагин для Cоmposer, который позволяет применять патчи к зависимостям. Прочитав описание, я подумал, что это именно то, что нужно.
Как использовать cweagans/composer-patches:
Убеждаемся, что при установке нашей библиотеки в проекте патч тоже применится.
Добавляем в composer.json следущие строки:
Казалось бы, при подключении пакета должна была быть попытка применить патч, но нет.
Обновляем пакеты, чтобы применился патч, но этого не происходит:
Порывшись в баг-трекере, я нашёл баг File based patches aren’t resolved in dependencies. Получается, нужно либо указывать URL до патча (а значит, скачивать его откуда-то), либо указывать путь до патча вручную в каждом проекте, где вы устанавливаете зависимость, требующую патчей.
Плюсы этого подхода:
Последний пункт стал для меня барьером. Сначала я завёл feature request. Мейнтейнер написал, что не хочет добавлять эту фичу в основной код, но во второй версии можно будет написать плагин (да, плагин для плагина для Composer). Перспективы выхода второй версии были туманными, поэтому я решил поискать альтернативы. Среди небольшого списка я не нашёл плагина, который бы поддерживался.
Лезть в код плагина не хотелось, поэтому я решил прошерстить форки — наверняка кто-то уже сталкивался с проблемой и решил её.
Использование Vaimo Composer Patches
Такой хороший форк не должен теряться в куче других бесполезных форков. Поэтому я связался с автором с просьбой включить issues и добавить пакет на Packagist. Спустя почти месяц автор ответил и всё это сделал. 🙂
Использование vaimo/composer-patches не отличается от использования предыдущего плагина, но можно указывать разные патчи для разных версий.
Убеждаемся, что при установке нашей библиотеки в проекте патч тоже применится.
Создаём проект и устанавливаем mougrim/php-composer-patches-example :
На всякий случай можно убедиться, что наши изменения применились:
Плюсы этого плагина почти такие же, как у предыдущего, но ещё включают следующие:
Выводы
Подведём общие итоги:
Также я сделал косвенный вывод: если какая-то зависимость не предоставляет необходимый функционал, то, возможно, есть форки, которые реализовали этот функционал и даже больше.
В Badoo мы используем Vaimo Composer Patches в двух случаях:
Ринат Ахмадеев, Sr. PHP Developer
UPD1: Спасибо BoShurik за ссылку на алиасы. Добавил пункт про алиасы в статью.
Composer для самых маленьких
Когда я первый раз разбирался с composer, я набросал для себя маленькую шпаргалку и теперь, спустя некоторое время представляю её на суд общественности в несколько доработанном виде.
Данная публикация актуальная для тех, кто в первый раз столкнулся с незаменимым менеджером пакетов для PHP.
Итак, Composer — менеджер пакетов для PHP.
Для чего нужен Composer и простейший пример его использования
Возьмем для примера этот проект
Если в двух словах: то это набор скриптов для работы в VK API
Соответственно, для работы этих скриптов нужно несколько библиотек
Библиотеки перечислены в файле composer.json — ключевой файл при работе с composer
В этом проекте используется 5 библиотек. Соответственно, если разработчик решит опубликовать этот проект на github, то ему достаточно закинуть в репу саму папку со скриптами и составить composer.json, в котором будут описаны библиотеки, необходимые для работы этого проекта. Простота очевидна: в репу не нужно вслед за файлами прицепом тащить все нужные библиотеки. Занимает меньше места, проще распространять проект.
В папке scripts лежат непосредственно скрипты проекта, для работы которых и требуются эти 5 пакетов.
Запускаем установку пакетов:
После установки появляется папка vendor, куда складываются установленные пакеты и формируется файл autoload.php
Этот файл подключаем к проекту и всё — библиотеки подключены, можно спокойно с ними работать.
Простота очевидна: не нужно скачивать и подключать библиотеки и их зависимости самостоятельно, composer всё сделает за Вас. И вся эта пачка подключается одним единственным файлом autoload.php
Все пакеты, которые лежат в vendor, добавляются в автозагрузчик. При этом composer опирается на файлы composer.json, которые должны быть у каждого пакета. Формирование composer.json пакета — это задача разработчика пакета, от потребителя пакета требуется лишь описать в composer.json проекта, какие пакеты нужно подключить.
Это пример composer.json проекта:
Это пример composer.json пакета:
В секции require прописана зависимость этого пакета — библиотека guzzle http, необходимая для работы библиотеки getjump/vk. В данном случае, т.е. с точки зрения потребителя пакетов, всевозможные зависимости пакетов — это не наша «забота», с зависимостями composer разберётся сам.
Пространство имён пакета прописано в секции autoload
getjump\\Vk\\ — наименование пространства имён
src/getjump/Vk/ — директория, в которой лежат файлы с классами пакета
Работа с этой библиотекой в проекте:
Core и Friends — это классы библиотеки, которые разложены и прописаны в папке src в соответствии со стандартом PSR-4. Опять же формирование структуры пакета — это работа создателя пакета.
Нам, как потребителю пакета, достаточно прописать в наш проект
include ‘../vendor/autoload.php’;
и все эти классы и пространства имён будут отлично работать.
При этом нам не нужно заморачиваться и писать автозагрузчик. Composer это сделает сам при выполнении команды install.
Установка
Установка Composer глобально
1) Для начала нужно что бы путь к директории с интерпретатором PHP был прописан в переменной окружения path.
Проверим, так ли это:
php –version
Далее нас будет интересовать переменная path:
Вписываем путь к интерпретатору
*С давних времён у меня на компьютере лежит сборка xampp, сама сборка здесь нафиг не нужна, а вот интерпретатор с неё вполне подойдёт (версия PHP – 5.6).
3) Добавим в переменную окружения path путь к composer.bat, например для D:\bin должно получиться:
Дополнительно можно добавить в path
D:\Users\%userName%\AppData\Roaming\Composer\vendor\bin\
для того, что-бы было удобнее использовать инструменты, глобально установленные через Composer.
(У меня папка Users располагается на диске D, а на C создан симлинк на неё).
Всё, composer установлен и полностью готов к работе.
Ещё: при установке можно словить ошибку
[RuntimeException]
The APPDATA or COMPOSER_HOME environment variable must be set for composer to run correctly
Решение нашлось здесь github.com/composer/composer/issues/2033
Добавляем переменную APPDATA со значением D:\Users\GSU\AppData\Roaming
Установка Composer локально
Отличия глобальной и локальной установки
Команды запускаются по разному при локальной и глобальной установках:
Например:
Локально: php composer.phar require silex/silex
1.1
Глобально: composer require silex/silex
При глобальной установке этот файл не нужен. Composer запускается при любой текущей директории.
Команды
Синтаксис composer.json
Именование пакетов и варианты описания пакетов
Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки.
Если пакет оформлен в соответствии со стандартом PSR-4, но опубликован не на packagist.org, а на github, то вместо версии пакета нужно прописать ветку и репозиторий для этого пакета:
Пример подключения библиотеки, которая лежит на github, но при этом не оформлена по стандарту PSR-4, а представляет из себя обыкновенное нагромождение файлов с классами и функциями.
Pqr/superlib — эта та самая «неправильная» библиотека.
В секции repositories для неё пишем такую конструкцию
Ключевой момент — секция autoload, здесь указываем нужные нам файлы с классами и функциями.
Структура библиотеки:
