And you beat me to it! I started working on the exact same thing yesterday. You can currently observe the lack of code in my GitHub repo for this .
Though what you are currently going is only a subset of what I had in mind. One can retrieve package info from Packagist (and perhaps the other repositories listed in composer.json), which URLs like . This can be used to enrich the information of installed extensions (and perhaps other packages as well), in particular with what the latest version is.
And when we know there is an update, we can actually show an update button, that when clicked, causes the corresponding composer command to be executed. Furthermore, we do not need to limit this to updating. We can display a list of available MediaWiki extensions that are not installed yet. A list of MediaWiki extensions can be obtained from Packagist via .
So I'm imagining having a "installed stuff" page, with tow sections: first extensions, then libraries. A second page would be for "stuff that can be installed". Perhaps this can be on the same special page but use tabs? That question is getting a bit to UI for me.
At this point there is no way to filter by supported MW version, or to specify this in the page definitions to begin with. I plan to investigate this, though good if someone gets it done before me.
The two API urls from Packagist listed [1, 2] I got from the Packagist maintainer after chatting with him. They are not documented, though are supposed to be stable. Furthermore there is no way to get package info in batch now, the .json urls need to be hit one by one.
Since MW 1.22 is going to ship with the barest beginnings of Composer
support, I think we should extend Special:Version to support this.
For now, though, we can add hooks -- do you have any suggestions?
If you go for what I just described, which I think we should (and if people disagree, I'll be hacking up a proof of concept regardless), then putting this all on Special:Version really makes no sense. Special:ExtensionManager is what I came up with.
Having an additional list there might be nice, and can be done without to much hassle, at least technically. There are quite some core people screaming murder at libraries like Diff showing up on Special:Credits (though being cynical about it, I'd not be surprised if they where actually just upset about my name being there) already, so I'm with James in thinking that attempting real integration here is likely to result in a lot of wasted time and effort.
Perhaps it is more worthwhile to, when a nice little initial implementation of extension management stuff on top of Composer is done, try getting that extension bundled with core by default. In this case I figure putting it in core even makes sense, as it is functionality one almost always desires. That means adding new clean code to core though, which is like locking an insentient person in a jail with some big bloke criminals. Poor code.
James: I outlined these ideas here in part so you could go ahead and do more awesome stuff already. I might be able to get to poking more at this tomorrow evening, though quite possibly only on Thursday. In any case, I'd appreciate a heads up if you want to poke at any of the additional stuff described, so we don't end up doing the exact same work there. I'm thinking the functionality should be in the same component/repo, as it has quite high cohesion and makes sense together functionality wise. Even if you already end up implementing all of the things to be done here functionality wise before I can get to it, I'd still like to contribute by improving some things in the code. Like fixing some of those annoying naming issues you currently have in there, mostly without even bothering you about them :D
Also, did you steal  from [4 and 5], or is this an instance where we where also thinking the same thing, but I won the implementation race? This shows clearly that the lack of decent interfaces in the i18n "component" provides by core is a general issues for anyone working on top of MW. I think a component that does the same for i18n as what WikibaseDatabase did for db interaction is in order. I was planning to create that as soon as I ran into the need of ,  or similar somewhere else, though again, if someone beats me to it, great.