Closed Rarst closed 11 years ago
Is the idea that people who bundle this into plugins could keep up with updates this way? That is, it would be for devs who use it, not end users?
Yep. Composer is dependency management so dev stuff. It replaces committing a copy of library into your plugin or adding it as subrepository with listing it as dependency in its composer.json
configuration file.
So in plugin I work on right now I have something like this in its composer.json
(I set up stub definition for TLC Transients in my custom Composer repo http://www.rarst.net/packages.json ):
"require" : {
"markjaquith/wp-tlc-transients": "dev-master"
},
"repositories": [
{
"type": "composer",
"url" : "http://rarst.net"
}
],
So when I install my plugin with Composer copy of TLC Transients is automagically downloaded (or checked out from GitHub depending on command, settings and environment) and made available to plugin.
I am still exploring Composer with WordPress and it's not all smooth (mostly due to WP being legacy code base from the view point of PHP 5.3+ world), however it's fantastic tool and is quickly becoming de-facto standard for sharing and reusing PHP libraries.
It replaces committing a copy of library into your plugin or adding it as subrepository with listing it as dependency in its
composer.json
configuration file.
But users aren't going to have this so wouldn't you have to commit the copy to your plugin? Just you could use this to keep the dependency up-to-date?
But users aren't going to have this so wouldn't you have to commit the copy to your plugin?
Quick comparison to subrepo approach. With subrepo:
With Composer:
There aren't many Composer-powered plugins for WP around yet. For example I have recently released Laps (composer.json
)
Minimal effort:
composer.json
informationMedium effort:
Optional:
Opinions? I can get this done easy, just don't want to bother if there is no interest in adopting it.