Composer repository

[jazzsequence]

A(nother) thought occurred to me today as I was adding the FAIR plugin to a Composer-based site of mine...correct me if I'm wrong but...

Composer-based WordPress sites will not benefit from hooking into the FAIR protocol via the plugin.

Those sites would benefit from the other stuff the plugin does (internal alternatives for Gravatar, various -Happy APIs, etc), but largely packages (plugins/themes) would either be sourced from the developers directly (e.g. roots/wordpress, humanmade/two-factor via Packagist or things like rhubarbgroup/object-cache-pro via their own Composer repo), or indirectly via api.wordpress.org through WPackagist which just mirrors WordPress.org SVN.

Is an alternative to WPackagist (FAIRPackagist, or I guess AspirePackagist?) a thing that is being considered for Composer-based sites, or is that demographic small enough to not be considered until a future (e.g. post 1.0) release?

[joedolson]

I don't think we've specifically discussed this, but I think it's a good idea.

[Ipstenu]

We've talked about it, but it's a down-the-line thing. One thing composer doesn't do is solve the single-point-of-failure-for-distribution issues. You could point a composer WPackagist setup at a FAIR repo, but redirecting installs like we do with FAIR doesn't really help in the case of composer. The only way to change a composer setup is to move from wpackagist-plugin/hello-dolly to fairpackagist/hello-dolly but you're still not really getting a non dev way to do that :/

[jonathan-dejong]

As an agency using the composer approach it would be great to have a fair alternative to wpackagist that also do not depend entirely on wordpress.org API (in the long run I suppose).

Extra bonus if it can act as an aggregator to other third party vendors of plugins, kind of like satis.

We would have no problem doing an update or our package names to reflect that.

but you're still not really getting a non dev way to do that :/

Frankly I don't really understand this statement. Composer is a dev tool to begin with.

[Ipstenu]

The comment about a non-dev way is that we're concentrating first on making this process a drop-in easy replacement for non-developer usage. Most users just want to install WP and its plugins.

This is not to say that the developer building process doesn't need love too, but it's not our top priority :)

One thing composer doesn't do is solve the single-point-of-failure-for-distribution issues

This is the biggest hurdle I think. If we can overcome a single point of failure, point to an API that finds a known package and installs it from a safe source from a list of sources, then we're properly distributing :)

[jonathan-dejong]

That's understandable! What I mean is that there is no reason to dismiss or defer a solution to composer based distribution with the argument that it requires a dev to change the package name required. 😊

I also believe this

point to an API that finds a known package and installs it from a safe source from a list of sources, then we're properly distributing

Is very close to what Satis is solving, maybe not at the scale fair or aspire would need it to operate (I don't know, only ever used it for agency private repos). But I feel like that API could take the shape of "an open source Composer repository generator."
https://composer.github.io/satis/

[Ipstenu]

What I mean is that there is no reason to dismiss or defer a solution to composer based distribution with the argument that it requires a dev to change the package name required.

Yeah I see how what I wrote sounded like that! It was meant as a reason to lower the priority is all :) English is hard sometimes!

We'll have to look into Satis!

[toderash]

@jonathan-dejong this came up on today's tech call (2025-09-29). No final decisions yet, but it's definitely on the radar with the TBD being more when and how than if; I think everyone wants this.

Speaking for myself, I think this has always been an intended part of the roadmap at some point, though so far it hasn't been tagged for a release or date. We are talking about system configurations that are specifically intended to support Agency or enterprise deployment pipelines, including private aggregation of a curated list of packages. Composer could potentially fit into more than one type of configuration. So far it's mostly theoretical, but pretty sure that requests and input will help shape it.

[jonathan-dejong]

Thank you for letting me know!
That is great to hear and I really think this will be a great thing for many agencies.

One thing came to mind when I was thinking about how I talked about FAIR internally in our company. With composer support in place and ideally with private aggregation adopting FAIR and especially running a node for distribution gains a lot of incentive for agencies.

If I could go to our management and tell them that if we set up and run one or more FAIR nodes we can not only contribute to a free open source WordPress but also gain faster builds/deploys and a centralised way to manage all our private packages that's big.
That's something which would be a lot easier to "sell" to internal stake holders and by extension both make the adoption and stability of the FAIR system easier.

Just some additional food for thought :)

[michakrapp]

There is now an open-source version of wpackagist from the roots team
https://wp-packages.org/

But it still syncs the packages from wp.org

[retlehs]

Happy to work with anyone who makes a mirror to support it first party on WP Packages

Or WP Packages could just be forked to setup the Composer repository the way you want

(The full infrastructure is open source)

[jonathan-dejong]

I was literally thinking about this yesterday.
It makes sense to me to pair up Fair and WP Packages to fully open source the whole "supply chain".. if we can run a node + a fork of WP Packages to also fully support our own private plugins etc. then this becomes so much easier to sell to internal stakeholders in agencies etc.

• Fastest delivery
• Fully open sourced
• Both our private and WP packages
• We help the community by running a node
• Only cost is our time and some server storage

That's a good pitch IMO.

[toderash]

As of a week ago, we have composer support in the pipeline for FAIR, with working proof-of-concept. We have a minor amount of work to hook it all up for release, but the concept is you'll be able to add a fair repository to your composer.json like so:

{
    "repositories": [
        {
            "type": "fair",
            "packages": {
                "vendor/package-name": "did:plc:abc123"
            }
        }
    ],
    "require": {
        "vendor/package-name": "*"
    }
}

or just do composer fair:require did:plc:afjf7gsjzsqmgc7dlhb553mv

This implementation method is fully open and would install from the AC package mirror via Fastly rather than from .org, so it's fundamentally the same in providing Composer support, but fundamentally different in how the packages are actually delivered through a much-improved supply chain.

[jonathan-dejong]

That is great!
What is the AC package mirror? Im not familiar ..

[toderash]

Ah, okay. AspireCloud (AC) is the package aggregator that serves the list of available packages/plugins, and provides the download URLs. In providing the URL, it rewrites the w-org destination with a Fastly CDN URL that fronts a full mirror of dot-org plugins & themes that we maintain to be publicly available.

On the Composer support, I need to give the update that it's not quite as far along as I had initially thought. We have a working proof-of-concept, but we had to punt it from the current release of FAIR Connect (the WP plugin part) to the next one since we just did a code freeze on version 1.4.

I'd invite you to pop into our Slack channels at chat.fair.pm and jump into the conversation there - if you're up for working on this feature specifically, you'll find some people to organize with and help get you up to speed on what's been done and yet to be done for this. It's a popular feature that we've all wanted to add, but have had a lot to do on other fronts as well.