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 сообщества.
Поделиться
doctor Brain
мир глазами веб-разработчика
Современный PHP разработчик (composer)
Пакетный менеджер composer
время чтения 10 мин.
Содержание
Пакетный менеджер
Обычно, функционально завершенный блок кода формирует метод, группа методов объединяется в составе определенного класса, набор классов составляет пакет.
Повторно используемые пакеты, в свою очередь, являются частью различных проектов, и не подвергаются, при этом, модификации. Такие пакеты позовляют решать строго опредленные задачи, обеспечивая взаимодействие с клиентом через API.
Использование пакетов способствует соблюдению современных принципов разработки программного обеспечения, например, DRY: “Don’t Repeat Yourself”, значительно уменьшая количество дублирующейся информации всех видов.
В большинстве случаев, у пакетов есть зависимости. Когда для работы “Пакета A” требуется “Пакет B”, мы говорим, что “Пакет A” зависит от “Пакета B”. Довольно часто для пакета формируется цепь таких зависимостей (“Пакет A” зависит от “Пакета B”, “Пакет B” зависит от “Пакета C”, список можно продолжить).
Представьте, что пакетных менеджеров не существует. Какие действия необходимо осуществить, для того чтобы обеспечить работоспособность “Пакета A”, зависящего от “Пакета B”? Для начала мы скачаем исходный код “Пакета A”, после чего обнаружим, что его функциональность зависит от “Пакета B”. Поэтому мы приложим максимум усилий, для того чтобы найти исходный код “Пакета B”. Но такой алгоритм может и не сработать, потому что мы не уверены, что в результате скачивания получим нужную версию “Пакета B”. Эту историю можно продолжить, а она касается только одной зависимости. Представляете, каким кошмаром обернется наличие у необходимого пакета множественных зависимостей или их цепочки.
Composer vs. PEAR
Кое-что с названием PEAR было еще до появляения Composer. Разработчики PHP с многолетним стажем наверняка знакомы с PEAR. Этот продукт сущестует с 1999 года. PEAR, как и Composer, был создан с целью развития инфраструктуры повторного использования пакетов. Тем не менее, по ряду причин он был отвергнут сообществом разработчиков:
Composer
Экосистема Composer содержит две части:
Пакетный менеджер уровня приложений управляет зависимостями только в пределах проекта. Это значительно облегчает управление проектами и предохраняет рабочее место от хранения большого количества ненужных файлов. Все необходимые пакеты хранятся в директории конкретного проекта.
Каждый разработчик может выкладывать свои пакеты в Packagist. В отличие от PEAR, нет необходимости набирать какие-то голоса. Тем не менее, популярность вашего проекта определяется собранными звездами.
Packagist
Установка Composer
Существуют два варианта установки Composer: локальный и глобальный. Исходя из профессионального опыта, мы рекомедуем выбрать глобальную установку: скорее всего Вы будете использовать Composer для управления зависимостями во всех своих PHP-проектах. Глобальная установка избавляет от большого количества ненужных хлопот в перспективе.
Composer предлагает удобный установщик, который запускается из командной строки, актуальную версию можно взять здесь (в связи с тем, что инсталяционный код меняется по мере выхода новых версий продукта, нет смысла выкладывать его в этой статье).
MacOS/Linux/Unix
Windows
Достаточно скачать и запустить установщик для Windows.
Актуальную информацию о глобальном и локальном вариантах установке Composer в различных операционных системах можно узнать здесь.
Проверка установки
Если результат будет подобен этому, установка выполнена верно:
Работа с Composer
Теперь Composer готов к работе. Рассмотрим небольшой пример:
Допустим, мы завершили работу над проектом, но для демонстрации его возможностей клиенту нужно сгенерировать пул даных: имена и адреса пользователей. Конечно, есть желание, чтобы такие данные выбирались случайным образом и, вообще, были максимально похожи на реальные. Одно из решений: самостоятельно создать массив имен и адресов, а затем случайным образом выбирать из него значения с помощью функции array_rand(). Надеюсь, Вы понимаете, что это непрактичное и скучное решение. А что делать, если нам понадобятся сотни пользовательских данных? Нужно найти альтернативное решение.
Давайте установим Faker с помощью Composer.
Из корневой директории проекта выполним команду:
Для установки пакета потребуется всего лишь несколько секунд. За это время Composer скачает zip-архив Faker с GitHub и создаст несколько внутренних файлов и папок.
После установки пакета в директории проекта можно обнаружить новые папки и файлы:
composer.json
Этот файл описывает зависимости в проекте. Это просто JSON-файл, демонстрирующий установленные для данного проекта пакеты.
Рассмотрим три основные команды Composer:
composer require
В случае, когда при выполнении команды composer require не указана необходимая версия пакета, происходит скачивание последней доступной версии.
В этом случае произойдет не только скачивание пакета установленной версии, но и корректное обновление соответствующих файлов Composer.
composer install
Возникает вопрос: в чем различия?
Эта команда обычно используется в 3 случаях:
composer update
composer update никогда нельзя использовать на продакшене
Как избежать такой ситуации? Рекомендации просты:
Соблюдение этих нехитрых условий позволит вам быть уверенными в полном соответствии переносимых пакетов.
composer.lock
В то время, как composer.json определяет состав пакетов, необходимых для проекта, и накладывает ограничения на используемые версии пакетов, composer.lock определяет точные версии пакетов, установленных в проекте. Иными словами composer.lock сохраняет текущее состояние проекта. Это очень важный момент, который необходимо знать.
Рассмотрим следующую ситуацию. Случайно из проекта удалили папку vendor со всеми установленными пакетами. Что делать? Достаточно запустить команду composer install и будут установлены все необходимые версии пакетов, используемых в проекте.
Это зависит от весьма простых условий:
Composer дает определенные свободы в использовании своих команд. Но существует несколько правил, которые лучше соблюдать, чтобы избежать неприятные ситуации:
Автозагрузка
В нашем случае, для использования возможностей пакета Fake, достаточно просто подключить автозагрузчик:
после этого Faker готов к работе:
Сообщество
Итак, Вы получили достатчные знания о менеджере зависимостей Composer. Приступайте к его использованию в своих проектах. Можно гарантировать, что это значительно облегчит Вашу работу, как личную, так и в составе команды. Не забывайте обращаться к Packagist, перед тем как приступить к созданию собственного функционала. Используйте все возможности сообщества.
Разберёмся с Composer
В этой статье я постараюсь раскрыть некоторые моменты, которые часто бывают непонятны начинающим осваивать Composer пользователям. Я не буду рассказывать что такое Composer и как установить. Такой информации уже предостаточно. А вот что такое composer.lock файл или почему команда install не устанавливает указанный пакет смогут ответить не все. Поэтому давайте пробежимся по этим вопросам.
При рассмотрении возможностей Composer я буду ссылаться на фреймворк Laravel, так как пишу для пользователей MODX, которые как и я хотели бы познакомится с этим фреймворком поближе.
Минимальные требования — понимать, что такое менеджеры зависимостей и в частности Composer, и разобраться с его установкой.
Composer install
Пакеты, которые Composer должен установить перечислены в секциях «require» и «require-dev». Это так называемые зависимости. Для каждого пакета указана версия. У многих, кстати, часто возникает вопрос по назначению этих секций. Мы это рассмотрим дальше. А пока вернёмся к установке.
и, например, на момент разработки у вас установлена версия 1.1, то в composer.lock будет указана версия 1.1. Тогда ваш коллега при установке получит ту же версию пакета, которая установлена у вас, даже если вышла новая версия 1.2. Именно поэтому практически всегда проекты имеют файл composer.lock в репозитории. Ещё один плюс — в этом файле указаны все зависимости всех пакетов, поэтому при разворачивании проекта не нужно заново определять все эти зависимости, что существенно экономит время.
Composer update
Команда update имеет следующий синтаксис:
Надеюсь вам всё понятно. Если да, то кивните.
Composer require
Эту команда используется, когда нужно установить один или пару пакетов. В консоли достаточно набрать
Можно указывать несколько пакетов подряд.
Composer remove
Никогда не удаляйте пакеты вручную из директории vendor! Это сломает зависимости Composer.
Для начала этого вполне хватит, чтобы понимать как работает Composer. В дальнейшем, когда неуверенность пройдёт, освоить другие команды будет уже проще. А теперь как и обещал расскажу чем отличаются секции «require» и «require-dev».
Зависимости «require» и «require-dev»
Давайте разберёмся для чего они нужны. В секции «require» указываются пакеты, которые необходимы для работы проекта (сайта или пакета). Это могут быть комментарии, админка, функции для работы с датами и т.п. В секции «require-dev» указывают пакеты, необходимые только для разработки и не влияющие на работу самого проекта.
Но внимательные заметят, что при установке или обновлении Composer устанавливает пакеты из обоих секций. Тогда возникает вопрос — а зачем их делить? Всё просто. Это разделение условное и им управляете вы сами. Composer сам не может определить, где он запускается — на сервере разработки или продакшене. Поэтому, при разворачивании проекта на production сервере, нужно указать Composer, чтобы он не устанавливал пакеты для разработки из секции «require-dev».
Ещё очень важное замечание. Пакеты из секции «require-dev» устанавливаются только для корневого пакета. Т.е. у зависимых пакетов Composer эту секцию не учитывает. Логика простая — если вы хотите доработать какой-то пакет и вам нужны пакеты для разработки, то установите его напрямую.
Версии
При указании зависимостей в файле composer.json необходимо указать версию пакета. Давайте рассмотрим варианты определения этих версий.
Точная версия
Вы можете указать точную версию пакета. Тогда Composer установить именно эту версию. Если для других зависимостей требуется иная версия, то процедура установки или обновления прервется с ошибкой.
Диапазон
Вы можете определить несколько диапазонов. Диапазоны, разделенные пробелом или запятой, будут рассматриваться как логические «И». Две вертикальные черты (||) будут рассматриваться как логическое «ИЛИ». «И» имеет более высокий приоритет чем «ИЛИ».
Диапазон через дефис
Определяет диапазон с минимальной и максимальной границей версий. Если в правой части указать неполную версию, то она будет дополнена подстановочным знаком «*» (wildcard).
Подстановка (*)
Для определения любых значений можно использовать шаблон со знаком *.
Тильда (
Данный вариант похож на подстановку, но имеет одно отличие — можно указать нижнюю границу версии. Т.е. последняя цифра указанной версии может быть любой, не не ниже указанной.
Каретка (^)
Каретку ^ часто используют при семантическом версионировании и для разрешения непрерывных обновлений. Её указывают для ограничения мажорной версии, чтобы гарантировать обратную совместимость.
Ветка git
Коммит
Заключение
Надеюсь, эти базовые знания помогут быстрее вникнуть в принцип работы Composer.
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 ):
