The PHP composer features should use the v2 metadata from Packagist

[stof]

Package manager/ecosystem composer Manifest contents prior to update n/a Updated dependency n/a What you expected to see, versus what you actually saw

The code of the composer support is currently reading metadata from Packagist using the v1 metadata. This happens for instance in https://github.com/dependabot/dependabot-core/blob/0b286b2ac5a7a25059d158cc85f2613c3a30d937/composer/lib/dependabot/composer/update_checker/latest_version_finder.rb#L109 (there might be other places in the code reading such metadata too). Packagist supports a new metadata format (introduced for composer 2 as composer 1 does not know how to use it) for better performance and reduced bandwidth. The composer team plans to deprecate the v1 metadata format and disable it on packagist.org in the future (the schedule is not defined yet as that depends on the adoption of composer 2).

It would be great if dependabot could switch to using the endpoint of metadata v2, so that it is ready for this upcoming deprecation. This endpoint is at https://repo.packagist.org/p2/ instead of https://repo.packagist.org/p/

Note that you currently use the packagist.org domain rather than the repo.packagist.org domain, which forbids you from using the official metadata mirrors. If dependabot runs in a US-based datacenter, using the repo.packagist.org domain would allow you to hit the mirror in Montreal instead of hitting a server in Europe, improving latency. Doing that switch is unrelated to the v1 vs v2 metadata change though (both are mirrored by packagist).

The differences between the v1 and v2 metadata formats are documented in https://github.com/composer/composer/blob/master/UPGRADE-2.0.md#for-composer-repository-implementors. Here are the main highlights:

• metadata are minified (this can be detected based on the "minified": "composer/2.0" top-level key in the file) to reduce the file size thanks to the fact that most releases don't change most of the metadata fields compared to the previous release. This will probably impact dependabot as it will need to un-minify the metadata
• only metadata for the package itself are in the file, not other packages providing the same name (should not be an issue for dependabot if it cares about the versions for the package name it loads)
• dev versions (corresponding to git branches rather than tags) are in a separate file (most projects don't allow dev versions of their dependencies and so don't need the metadata for git branches. Splitting them allowed a better caching as releases happen less often than pushes to branches)
• absence of a package is now always represented by a 404 response rather than sometimes returning a 200 response with an empty list in the packages key.

[jeffwidman]

👋 hey @stof thanks for the heads up and sorry for the slow reply.

A couple of questions:

1. This was never backported to composer v1, right? Since we currently support both, we'd need to either drop v1 or intelligently flip between the metadata formats depending on whether we're using composer v1 vs v2.
2. I assume we can flip all composer 2 metadata calls to the new endpoint / format enmasse? Ie, no need to support the old metadata format?

[stof]

packagist.org exposes all its metadata in the v2 endpoint. There is no need to call the v1 endpoint (which is partial metadata as explained in https://blog.packagist.com/deprecating-composer-1-support/). To find the latest version of the package by calling the endpoint directly, you could always use the v2 endpoint, even if you are calling composer 1 after that to actually perform the update.