Composer-plugin-api ^1.0

0 views

Skip to first unread message

Allen Yerke

unread,

Aug 3, 2024, 1:28:04 PM8/3/24

to drinmomapul

Get Started Download SuiteCRM right now, create your free SuiteCRM account and get started! Latest version Latest LTS version Upgrades Latest Pre-Release Pure SuiteCRM. Nothing hidden. Everything to play with.Download...

I get the following message
Composer autoloader not found. please run "composer install"
when running composer install it complains that there is an issue with the version for composer-plugin-api and that you should try running composer update but this also fails.

Composer, PHP dependency manager was released about 8 years ago, and its second major version is just around the corner. Over the years, Composer received many new features, and kept up with PHP standards. Composer version 2 will be mostly compatible with your existing workflows, while bringing some more great new features.

Here is a comparison between composer v1.10.5 and v2 (40a35ab) to run composer require laravel/laravel. The test was done on an empty cache, followed by a new test after the cache is primed. The test results are the average of 5 runs on consumer hardware.

When curl is present, multiple packages/API calls will be downloaded all at the same time, reducing the overall download time. Furthermore, Composer v2 will make use of HTTP/2, and share TLS sessions, and DNS responses between HTTP requests to speed up downloads.

You can prevent Composer v2 from attempting to make any network requests. This can come handy if you want to run benchmarks, or if your Internet connection is faulty. Composer v2 will try to install the packages provided a composer.lock file exists and all packages and meta data are cached.

Composer v2 supports a new format for its repository meta data. Traditionally, Composer metadata files were large sharded JSON files, which required a few megabytes of downloads. The new format is light-weight, and repository maintainers provide URL endpoints for individual packages, which Composer can request and cache.

When Composer looks up for a package, it queries all configured repositories, and finally, the default repository, which is packagist.org (unless configured otherwise). With Composer version 2, you can further control how Composer should work with multiple repositories in a single project.

With Composer v2, Composer will look for packages in all repositories configured in the composer.json files repositories property in the order they are set. If a package is found in a repository, Composer will not look for that package in any other repositories further down the line.

Composer v2 will consider all repositories to be canonical, and when a package is found in a repository, repositories with lower priorities cannot provide the same package, even if a newer version is available.

Canonical repositories help prevent accidentally installing packages from lower priority repositories (such as packagist.org) when the package is found in private or package-specific repositories. Without canonical repositories, Composer might install a package from a lower priority repository if a newer version is found.

Composer will look for packages that match drupal/* in the Drupal repo, and wpackagist-plugin/* and wpackagist-theme/* in WPackagist repos. If these repositories host packages for other vendor names, they will not be lookup up, nor used.

With settings above, all packages will be tried from the example.com repo, except for example/outdated-package. One use case would be a repository down the line hosting a newer version of the same package that you want to use instead of the one available at example.com.

About a decade ago, PHP had PEAR, or PHP Extension and Application Repository to install reusable packages. Composer naturally took over with its nicer user experience and vastly openness and ease of use. Composer v1 had support to install PEAR packages from PEAR channels by adding a custom repo with type pear.

During an installation or an update, all packages are locked first (updated in composer.lock), then downloaded to cache (in parallel if possible). After all files are successfully downloaded, or when found in cache, Composer extracts them to the vendor-dir. This prevents broken/incomplete state in the vendor-dir in case the network fails in the middle of the process.

Furthermore, the vendor/composer/installed.json file is refactored to use packages property store all package information (as opposed to the root level in v1). For each package, its installation path is now stored in an install-path relative to the installed.json file. This file also stores whether the require-dev packages were installed. Plugin maintains can make use of this information enhance their plugins.

This probably wouldn't surprise anyone. The plugin API provided by Composer v2 is marked 2.0. This will prevent plugins from being installed if they require composer-plugin-api with version constraint ^1.0.

If you maintain a Composer plugin, you will need to update this dependency to allow composer-plugin-api versions ^2.0. It may be possible to support both versions from the same version, as long as all new interface methods are implemented.

Finally, let's take moment to appreciate Jordi, Nils, and other contributors immense efforts in bringing Composer to PHP. Composer changed PHP as we knew it last decade, made a lot of things we do with PHP today possible. Thank you!

You will receive an email on last Wednesday of every month and on major PHP releases with new articles related to PHP, upcoming changes, new features and what's changing in the language. No marketing emails, no selling of your contacts, no click-tracking, and one-click instant unsubscribe from any email you receive.