Use v2 of Composer with the GitLab Package Registry
Problem to solve
Composer 2.0 adds support for a new Composer repository format. GitLab does not currently support v2 of Composer. This prevents Developers from taking advantage of the improvements included in Composer v2, including important performance improvements.
There are three items noted for registry providers to implement in order to support V2. One is mandatory, the other two are optional.
This issue will focus on the required item, support for the metadata URL
.
Proposal
Add support for v2 of Composer to GitLab Packages by adding support for the metadata-URL parameter.
📦
Metadata URL This is a new route that is required for V2:
/api/v4/groups/:id/-/packages/composer/p2/*package_name
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/bardev.json to look for foo/bar's dev versions). - Caching is done via the use of If-Modified-Since header, so make sure you return Last-Modified headers and that they are accurate.
- Any requested package which does not exist MUST return a 404 status code, which will indicate to Composer that this package does not exist in your repository.
- The foo/bar.json and foo/bar~dev.json files containing package versions MUST contain only versions for the foo/bar package, as {"packages":{"foo/bar":[ ... versions here ... ]}}.
- The array of versions can also optionally be minified using Composer\Util\MetadataMinifier::minify(). If you do that, you should add a "minified": "composer/2.0" key at the top level to indicate to Composer it must expand the version list back into the original data. See https://repo.packagist.org/p2/monolog/monolog.json for an example.
- 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).
Future development
New values in package.json
providers-api
This optional field will be handled in a future issue.
"providers-api": "https://packagist.org/providers/%package%.json",
The providers-api is optional, but if you implement 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 packages which have a "provide" rule for monolog/monolog, but it does not list monolog/monolog itself.
list
This optional field will be handled in a future issue.
It should accept an optional ?filter=xx query param, which can contain * as wildcards matching any substring.
It must return an array of package names as {"packageNames": ["a/b", "c/d"]}. See https://packagist.org/packages/list.json?filter=composer/* for example.
It should return the names of packages which names match the filter (or all names if no filter is present). Replace/provide rules should not be considered here.
Documentation
- Update the documentation to say which versions are currently supported
Testing
Part of the Package QA test suite, Test v2 of Composer