Вышла новая версия менеджера зависимостей Composer 2.0 для PHP
Появилась новая версия менеджера зависимостей PHP Composer 2.0 — первое полноценное обновление сервиса с момента его выхода в 2012 году. Подробно рассказываем, какие обновления менеджера вошли в этот релиз.
Улучшение производительности
Разработчики кардинально переработали Composer — начиная от протокола взаимодействия между Composer и packagist.org, заканчивая параллельным скачиванием файлов с помощью curl. Это значительно улучшило скорость работы и снизило потребление памяти. Конкретный прирост производительности зависит от способа использования Composer, но разработчики обещают, что пользователи утилиты будут приятно удивлены изменениями.
Разработчики указывают, что запуск composer require laravel/laravel на обычном потребительском оборудовании с Composer 2 при пустом кэше теперь тратит до 60% меньше времени, чем предыдущая версия менеджера.
Архитектурные изменения в загрузке и установке улучшений
Во время установки или обновления все пакеты будут сначала блокироваться и обновляться в composer.lock, и только после этого загружаться в кэш — при этом возможны ситуации, при которых эти процессы будут происходить параллельно. После того, как все файлы будут успешно загружены, Composer извлечет их в каталог vendor-dir — это позволит избежать не полного обновления каталога vendor в случае ошибки в работе интернета, либо других локальных проблем в работе пакета.
Улучшенные отчеты об ошибках
Не всегда всё идет так, как мы ожидаем. Если не удаётся разрешить зависимости, новый Composer генерирует более короткие и точные отчёты об ошибках, чтобы вам было проще в них разобраться.
Как обновить Composer?
Если у вас установлен Composer 1.x, запуск команды composer self-update лишь предупредит о выходе новой стабильной версии. Для обновления запустите команду composer self-update —2.
При возникновении проблем есть возможность откатиться обратно до первой версии менеджера при помощи команды composer self-update —1 . Можно спокойно экспериментировать с новой версией и не бояться что-нибудь сломать. Файл composer.lock совместим с обеими версиями, поэтому и с ним проблем при обновлении и откате на предыдущую версию не будет.
Разработчики также отмечают, что главной проблемой при обновлении версии менеджера могут стать плагины, часть которых еще не поддерживают Composer 2. В случае, если некоторые плагины не поддерживают новую версию менеджера, их можно отключить перед установкой. Делается это при помощи команды composer —no-plugins .
Что дальше?
Composer по-прежнему поддерживает PHP 5.3 и выше, однако в дальнейшем разработчики собираются отказаться от поддержки версий EOL PHP. Composer 1.x будет получать критические обновления какое-то время, но лучше обновиться до Composer 2.0 как можно скорее.
Настройка Composer: В профессии PHP-разработчик на Хекслете есть несколько уроков, где мы подробно разбираем, как настроить Composer и как вообще с ним работать.
Name already in use
composer / UPGRADE-2.0.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Upgrade guides for Composer 1.x to 2.0
For composer CLI users
- The new platform-check feature means that Composer checks the runtime PHP version and available extensions to ensure they match the project dependencies. If a mismatch is found, it exits with error details to make sure problems are not overlooked. To avoid issues when deploying to production it is recommended to run composer check-platform-reqs with the production PHP process as part of your build or deployment process.
- If a package exists in a higher priority repository, it will now be entirely ignored in lower priority repositories. See repository priorities for details.
- Invalid PSR-0 / PSR-4 class configurations will not autoload anymore in optimized-autoloader mode, as per the warnings introduced in 1.10
- On linux systems supporting the XDG Base Directory Specification, Composer will now prefer using XDG_CONFIG_DIR/composer over
/.composer if both are available (1.x used
For integrators and plugin authors
- composer-plugin-api has been bumped to 2.0.0 — you can detect which version of Composer you run via PluginInterface::PLUGIN_API_VERSION
- PluginInterface added a deactivate (so plugin can stop whatever it is doing) and an uninstall (so the plugin can remove any files it created or do general cleanup) method.
- Plugins implementing EventSubscriberInterface will be deregistered from the EventDispatcher automatically when being deactivated, nothing to do there.
- Pool objects are now created via the RepositorySet class, you should use that in case you were using the Pool class directly.
- Custom installers extending from LibraryInstaller should be aware that in Composer 2 it MAY return PromiseInterface instances when calling parent::install/update/uninstall/installCode/removeCode. See composer/installers for an example of how to handle this best.
- The Composer\Installer class changed quite a bit internally, but the inputs are almost the same:
- setAdditionalInstalledRepository is now setAdditionalFixedRepository
- setUpdateWhitelist is now setUpdateAllowList
- setWhitelistDependencies , setWhitelistTransitiveDependencies and setWhitelistAllDependencies are now all rolled into setUpdateAllowTransitiveDependencies which takes one of the Request::UPDATE_* constants
- setSkipSuggest is gone
- packages are now wrapped into a «packages» top level key instead of the whole file being the package array
- packages now contain an «installed-path» key which lists where they were installed
- there is a top level «dev» key which stores whether dev requirements were installed or not
- A new loadPackages(array $packageNameMap, array $acceptableStabilities, array $stabilityFlags) function was added for use during pool building
- search now has a third $type argument
- A new getRepoName() function was added to describe the repository
- A new getProviders() function was added to list packages providing a given package’s name
- download now receives a third $prevPackage argument for updates
- download should now only do network operations to prepare the package for installation but not actually install anything
- prepare (do user prompts or any checks which need to happen to make sure that install/update/remove will most likely succeed), install (should do the non-network part that download used to do) and cleanup (cleaning up anything that may be left over) were added as new steps in the package install flow
- All packages get first downloaded, then all together prepared, then all together installed/updated/uninstalled, then finally cleanup is called for all. Therefore for error recovery it is important to avoid failing during install/update/uninstall as much as possible, and risky things or user prompts should happen in the prepare step rather. In case of failure, cleanup() will be called so that changes can be undone as much as possible.
Detailed differences in event flow during dependency resolution, composer updates and installs
- Composer resolves dependencies (dispatching PRE/POST_DEPENDENCIES_SOLVING)
- It then iterates over all packages one by one (dispatching PRE_PACKAGE_INSTALL/UPDATE/UNINSTALL, then PRE_FILE_DOWNLOAD if needed, then POST_PACKAGE_*)
- And finally writes the lock file at the end
The update and install process have been split up.
- Composer resolves dependencies (dispatching PRE_POOL_CREATE)
- It then writes the lock file and that’s the end of the update
Install then does:
- Dispatches PRE_OPERATIONS_EXEC with the full list of operations to be executed
- Downloads all the packages not in cache yet in parallel (dispatching PRE_FILE_DOWNLOAD for those not in cache yet)
- It then iterates over all packages and executes updates/installs/uninstalls in parallel (dispatching PRE_PACKAGE_INSTALL/UPDATE/UNINSTALL then POST_PACKAGE_* but one package started last may finish installing before another is done for example).
For Composer repository implementors
Composer 2.0 adds support for a new Composer repository format.
It is possible to build a repository which is compatible with both Composer v1 and v2, you keep everything you had and simply add the new fields in packages.json .
Here are examples of the new values from packagist.org:
This new metadata-url should serve all packages which are in the repository.
- Whenever Composer looks for a package, it will replace %package% by the package name, and fetch that URL.
- If dev stability is allowed for the package, it will also load the URL again with $packageName
dev (e.g. /p2/foo/bar
If your repository only has a small number of packages, and you want to avoid the 404-requests, you can also specify an «available-packages» key in packages.json which should be an array with all the package names that your repository contain. Alternatively you can specify an «available-package-patterns» key which is an array of package name patterns (with * matching any string, e.g. vendor/* would make composer look up every matching package name in this repository).
The providers-api is optional, but if you implement it it should return packages which provide a given package name, but not the package which has that name. For example https://packagist.org/providers/monolog/monolog.json lists some package which have a «provide» rule for monolog/monolog, but it does not list monolog/monolog itself.
This is also optional, it should accept an optional ?filter=xx query param, which can contain * as wildcards matching any substring.
It should return the names of package which names match the filter (or all names if no filter is present). Replace/provide rules should not be considered here.
Как изменить версию composer: обновиться или откатиться на старую версию
С выходом второй версии composer, теперь она устанавливается по-умолчанию. Однако, некоторые приложения могут быть не полностью совместимы с 2 версией композера, поэтому вам, возможно, придётся использовать первую версию до тех пор, пока все несовместимости не будут устранены.
Именно из-за этого, в некоторых старых приложениях на Laravel вылетает ошибка: Laravel PackageManifest.php: Undefined index: name. Для того, чтобы исправить эту ошибку, нужно просто отказаться от использования второй версии composer и понизиться её до первой версии.
Чтобы понизить версию composer
Если по каким-либо причинам вам необходимо понизить версию композера (composer) до первой версии, вы можете выполнить следующую команду от имени root:
Как обновить composer до 2 версии
И, в обратном порядке, когда ваше приложение будет готово к обновлению, чтобы обновить composer до 2 версии, выполните команду от имени root:
Как узнать версию composer
Если вы не знаете наверняка, какая у вас версия composer, то для того, чтобы проверить установленную версию композера, выполните в консоли команду:
Затем проскрольте в самый верх, к надписи composer, где вы и увидите текущую версию композера:
Как обновить composer в проекте до > 2.*?
Добрый день, возник вопрос по composer`у.
В моем проекте (сайт на php) используется composer 1.9.3 (локально).
Есть нужда обновить его до последней версии (а также библиотеки) без потерь работоспособности проекта.
При использовании версии > 2.* возникают ошибки автозагрузчика и тд.Подскажите, по какому алгоритму можно провести данную операцию? 🙂
Возможно есть какие-либо нюансы в переходе с 1.* на 2.*- Вопрос задан более года назад
- 553 просмотра
- Вконтакте
сначала апгрейдите сам композер, затем пакеты.
проблем быть не должно (все актуальные пакеты уже переписаны под изменения композера).но таки лучше предварительно откатать на копии, а не рабочем проекте.
вторая версия — огонь. и переходить на неё нужно обязательно.
но могут быть проблемы со старыми (не поддерживаемыми) пакетами. тогда прост или ищите современную замену этому пакету, или конкретно для этого проекта пользуете старый композер.