PHP 7951 ~ 9 мин.

Composer 2: что нового, что изменилось

Composer 2: что нового, что изменилось

Менеджер зависимостей PHP Composer, был выпущен около 8 лет назад, и его вторая основная версия выйдет уже в октябре 2020 года

За эти годы Composer  следовал стандартам PHP и получил много новых функций. Composer v2 в основном будет совместим с вашими существующими рабочими процессами, но в то же время предоставит еще несколько замечательных новых функций.  Мелкие изменений в релизе предостаточно, ознакомиться с ними можно здесь.

Более быстрое время загрузки

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

Вот сравнение между composer v1.10.5 и v2 (40a35ab) для запуска composer require laravel/laravel. Тест был выполнен на пустом кеше, после чего был проведен новый тест после заполнения кеша. Результаты теста в среднем за 5 прогонов на потребительском оборудовании.

Composer v2 установил laravel/laravel больше чем в 2 раза быстрее без кеширования.

Повышение производительности происходит за счет параллельной загрузки метаданных пакета (которые также являются новыми конечными точками) и файлов zip пакета.

Когда установлен curl, несколько пакетов или вызовов API будут загружаться одновременно, что сокращает общее время загрузки. Кроме того, Composer v2 будет использовать HTTP/2 и совместно использовать сеансы TLS и ответы DNS между HTTP-запросами для ускорения загрузки.

Кстати, для Composer v1 плагин hirak/prestissimo принес эти функции довольно давно.

Частичная поддержка оффлайн

Вы можете запретить Composer v2 выполнять любые сетевые запросы. Это может пригодиться, если вы хотите запустить тесты или если ваше интернет-соединение неисправно. Composer v2 попытается установить пакеты при условии, что файл composer.lock существует и все пакеты и метаданные будут кэшированы.

Чтобы это работало, установите переменную окружения COMPOSER_DISABLE_NETWORK со значением 1. Файл  проекта composer.lock должен обязательно присутствовать для осуществления работоспособности.

Обратите внимание, что это полностью отключит Composer от сетевых запросов. Это не будет работать как запасной механизм.

С установленной переменной среды вы можете использовать команду composer install, как обычно. Composer выдаст предупреждение о том, что сеть отключена, но все равно продолжит работу.


https://repo.packagist.org could not be fully loaded (Network disabled, request canceled: https://repo.packagist.org/packages.json), package information was loaded from the local cache and may be out of date

Если пакет не доступен в кеше, вы получите сообщение об ошибке:


The required git reference for ayesh/php-timer is not in cache and network is disabled, aborting

Пробная поддержка require и remove команды

У команды composer update есть опция --dry-run, которая запрещает Composer вносить какие-либо изменения, но просто отображает вывод в терминале.

Composer v2 также предоставляет опцию --dry-run для команд composer require и composer remove, которые можно использовать для проверки установки/удаления пакета, не затрагивая реальные файлы проекта.

Запуск от root'а требует подтверждения

Плагины и скрипты Composer могут запускать произвольные команды в системе. Запуск Composer от имени root пользователя часто является плохой идеей, поскольку вредоносный плагин/скрипт может также выполнять команды root.

До версии 2 Composer выдавал предупреждающее сообщение при попытке запустить команду как root:


Do not run Composer as root/super user! See https://getcomposer.org/root for details

С Composer версии 2 вы получите интерактивное подтверждение:


Do not run Composer as root/super user! See https://getcomposer.org/root for details
Continue as root/super user [yes]?

Это подтверждение не появится, если оно не поддерживается на вашем терминале, не будет интерактивным. Вы можете принудительно включить этот режим, передав команду -n/--no-interactionflag. Например:


composer install --no-interaction

Новый формат метаданных репозитория

Composer v2 поддерживает новый формат метаданных репозитория. Традиционно файлы метаданных Composer представляли собой большие файлы JSON, которые требовали загрузки в несколько мегабайт. Новый формат облегчен, и сопровождающие хранилища предоставляют конечные точки URL для отдельных пакетов, которые Composer может запрашивать и кэшировать.

Packagist.org уже поддерживает этот формат. Если вы используете другие репозитории, ищите ключ metadata-url в файле packages.json.

Packagist возвращает это:


{
    "packages": [],
    "metadata-url": "/p2/%package%.json",
    "provider-includes": {...}
    ...
}

Когда metadata-url присутствует, Composer v2 будет использовать новую конечную точку метаформатов. Composer v1 продолжит использовать стандартный подход.

Каноническая, фильтрационная и разрешенная поддержка для нескольких репозиториев

Packagist.org - это хранилище по умолчанию для Composer. Но это не значит, что вы не можете использовать другие репозитории в своем проекте.

У Drupal есть официальный репозиторий Composer, а у WordPress есть неофициальный репозиторий, и, вероятно, у вашей команды/организации тоже есть.

Когда Composer ищет пакет, он запрашивает все настроенные репозитории и, наконец, репозиторий по умолчанию packagist.org (если не указано иное). С Composer версии 2 вы можете дополнительно контролировать работу Composer с несколькими репозиториями в одном проекте.

Приоритеты хранилища

В Composer v2 Composer будет искать пакеты во всех репозиториях, настроенных в свойстве repositories composer.json,  в порядке их установки. Если пакет найден в репозитории, Composer не будет искать этот пакет в каких-либо других репозиториях в дальнейшем.

Канонические репозитории

Composer v2 будет считать все репозитории каноническими, когда пакет найден в репозитории, репозитории с более низкими приоритетами не могут предоставить тот же пакет, даже если доступна более новая версия.

Канонические репозитории помогают предотвратить случайную установку пакетов из репозиториев с более низким приоритетом (например, packagist.org), когда пакет находится в частных или специфичных для пакета репозиториях. Без канонических репозиториев Composer может установить пакет из репозитория с более низким приоритетом, если найдена более новая версия.

Вы можете переопределить это поведение, пометив хранилище как не каноническое:


{
    ...
    "repositories": [
        {
            "type": "composer",
            "url": "https://example.org",
            "canonical": false
        }
    ]
    ...
}

Отфильтрованные хранилища

Composer v2 поддерживает директивы only и exclude в конфигурации хранилища. Они говорят Composer искать только пакеты с точным совпадением или совпадением с образцом в указанных хранилищах.


{
    "repositories":[
        {
            "type":"composer",
            "url":"https://packages.drupal.org/8",
            "only": ["drupal/*"]
        },
        {
            "type":"composer",
            "url":"https://wpackagist.org",
            "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
        }
    ],
}

Composer будет искать пакеты, совпадающие с drupal/* в Drupal репо, а также wpackagist-plugin/* и wpackagist-theme/* в WPackagist репо. Если в этих репозиториях размещаются пакеты с именами других поставщиков, они не будут искаться и использоваться.

Если в этих хранилищах не размещен пакет, соответствующий only хранилищу, они все равно будут искаться другие хранилища в дальнейшем.

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


{
    "repositories":[
        {
            "type":"composer",
            "url":"https://example.com",
            "exclude": ["example/outdated-package"]
        }
    ],
}

При указанных выше настройках все пакеты будут опробованы в example.com репозитории, кроме example/outdated-package. Одним из вариантов использования будет хранилище, в котором размещается более новая версия того же пакета, который вы хотите использовать вместо той, которая доступна на example.com.

Pear хранилище удалено

Около десяти лет назад PHP имел PEAR, или PHP Extension and Application Repository для установки повторно используемых пакетов. Composer, естественно, одержал победу благодаря своему приятному пользовательскому опыту, огромной открытости и простоте использования. Composer v1 поддерживал установку пакетов PEAR из каналов PEAR , добавляя пользовательское хранилище с типом .pear

Вы все еще можете установить любые пакеты PEAR, которые были размещены на php.net, просто установив с использованием префикса pear/ поставщика пакета. Поддержка пользовательских репозиториев PEAR удалена в Composer v2.

Ваши существующие пакеты PEAR с pear/ пакетами, вероятно, продолжат работать, если они переместились в pear/ пространства имен поставщика (что имеет место почти для каждого поддерживаемого пакета).

Опция --no-suggest удалена

Composer v2 удаляет параметр --no-suggest, который был доступен в командах require и update. Предлагаемые пакеты теперь всегда отображаются, но их описание ограничено одной строкой, чтобы предотвратить чрезмерно длинный вывод терминала.


[Symfony\Component\Console\Exception\RuntimeException]
  The "--no-suggest" option does not exist.

Быстрый поиск в GitHub показывает более 400K репозиториев с YAML-файлами (часто используемыми в конфигурации CI) с опцией --no-suggest, которая выдаст ошибку выше с Composer v2.

Блокировка, загрузка и установка улучшений рабочего процесса

Composer v2 теперь имеет улучшенный рабочий процесс для установки пакетов и обновлений.

Во время установки или обновления все пакеты сначала блокируются (обновляются в composer.lock), а затем загружаются в кэш (если возможно, параллельно). После того, как все файлы успешно загружены или найдены в кеше, Composer извлекает их в каталог vendor-dir. Это предотвращает неисправное/неполное состояние в каталоге vendor в случае сбоя сети в середине процесса.

Кроме того, файл vendor/composer/installed.json реорганизован для использования свойства packages, в котором хранится вся информация о пакете (в отличие от корневого уровня в v1). Для каждого пакета его путь установки теперь хранится в install-path относительно файла installed.json. Этот файл также хранит информацию о том, были ли установлены пакеты require-dev. Поддерживаемые плагины могут использовать эту информацию для улучшения своих плагинов.

Composer-plugin-api сейчас 2.0

Это, вероятно, никого не удивит. API плагина, предоставляемый Composer v2, помечен 2.0. Это предотвратит установку плагинов, если они требуют ограничения composer-plugin-api  версии ^1.0.

Если вы поддерживаете плагин Composer, вам необходимо обновить эту зависимость, чтобы разрешить composer-plugin-api версии ^2.0. Может оказаться возможным поддерживать обе версии, если реализованы все новые методы интерфейса.

Прежде всего, плагины должны теперь реализовать методы PluginInterface::deactivate() и PluginInterface::uninstall(). Вы можете взглянуть на другие реализации плагинов по этой проблеме.

Этот раздел документации Composer содержит больше информации и сводку изменений.

Как обновиться до Composer v2?

UPD 24.10.2020г. Если вы запустите 


composer self-update

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


composer self-update --2

Если у вас есть плагины, которые не работают, их можно временно отключить с помощью


composer --no-plugins

Если у вас возникнут проблемы, вы можете откатиться до первого композера в любое время, используя

composer self-update --1

Надеюсь, благодаря этому все смогут поэкспериментировать с новым релизом. Если вы обнаружите какие-либо ошибки или у вас есть предложения, создайте issue или pull-запрос .

Наконец, давайте потратим немного времени на то, чтобы поблагодарить Jordi, Nils и других участников за огромные усилия по переводу Composer на PHP. Composer изменил PHP, каким мы его знали в прошлом десятилетии, сделал возможным многое из того, что мы делаем сегодня с PHP. Спасибо!

Что дальше?

Composer 2.0 поддерживает PHP 5.3+, который на данный момент уже очень устарел и не дает в должной степени поддерживать ваш код. Разработчики приложили усилия, чтобы убедиться, что каждый пользователь Composer без проблем может перейти на Composer 2, но так же они планируют отказаться от поддержки версий EOL PHP в следующих выпусках. 

Что касается Composer 1.x, то сейчас он более-менее подходит к концу жизненного цикла . В него также периодически будут вноситься критические исправления, если что-то произойдет, но цель для всех - как можно скорее перейти на версию 2.x.

 


Что думаешь?

Категории
  • PHP 65
  • Заметки 15
  • Безопасность 3
  • Флуд 2
  • Nginx 2
  • ИТ новости 2
  • Видео 1
  • Docker 1
  • Roadmap 1
  • Архитектура 0

Хочешь поддержать сайт?

Делаем из мухи слона

sergeymukhin.com

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

Релизы PHP 8.4

Дата Релиз
8 Июня 2024 Альфа 1
20 Июня 2024 Альфа 2
04 Июля 2024 Альфа 3
16 Июля 2024 Feature freeze
18 Июля 2024 Бета 1
01 Августа 2024 Бета 2
15 Августа 2024 Бета 3
29 Августа 2024 RC 1
12 Сентября 2024 RC 2
26 Сентября 2024 RC 3
10 Октября 2024 RC 4
24 Октября 2024 RC 5
07 Ноября 2024 RC 6
21 Ноября 2024 GA

Что нового?