Composer repository for dynamic packages receives no param for searched package?

[franz-josef-kaiser]

I am in the process of building a Composer proxy service/ repository. Idea of the mini-service is to dynamically deliver language/ translation packages for themes or plugins from WordPress API responses. The routes are the following:

 https://api.wordpress.org/translations/plugins/1.0/?slug={slug}&version={version}

The Nodejs-service itself is nothing than a proxy that should be added as repository to a composer.json of type:project. The service itself returns the providers-url-key as part of the (dynamically generated) packages.json file.

"providers-url" : "/" + request.params.scope + "/providers/%package%$%hash%.json"

For an example, please see the following composer.json:

{
    "name"              : "vendor/testproject",
    "type"              : "wordpress-project",
    "minimum-stability" : "dev",
    "repositories"      : [
        {
            "type" : "composer",
            "url"  : "https://{unique-ID}.ngrok.io/test"
        }
    ]
}

So far I can only see requests to /endpoint/packages.json, but without any params. In an ideal world Composer would send along the required packages, either as header or as query param.

I already looked (and tested) through all available options to try to fake my way through the system to somehow get the requested package: type:{composer|vcs|…}. Is there a way to make this happen? Or is there at least the will to accept a PR to implement this – alongside an additional flag to enable that behavior?

A note regarding hosted services: there could be a combination of notify-batch and request/require options to gather some stats about searched and actually fetched repositories. This approach might allow to target "to-cache" packages much better.

[Seldaek]

This isn't possible at the moment, and I doubt it will be for a while.. Maybe in v2.0 once we have refactored the pool stuff we could achieve this. I'll leave open for now but don't hold your breath :)

[franz-josef-kaiser]

@alcohol I guess you can adjust the labels now :)

[Seldaek]

Closing as I don't really see this happening, might be doable with the v2 metadata (track #8248 if you're interested in more details) as you can do metadata-url: "/p2/%package%.json" there and all packages required will be called one by one, but you can only return data for that package's name not other packages tho so not sure it really helps you.

It does let you generate packages on the fly tho to some extent, so you could make the plugins require on foo/plugin-translations-en and then make sure you always return a package to make sure it's installable, either one with valid translations inside or an empty metapackage installing nothing if no translations are available?