Add Composer support

[Rarst]

Minimal effort:

• add composer.json information
• start versioning/tagging releases

Medium effort:

• break out definitions into separate files
• set up autoload for Composer use
• tweak bootstrap file for non-Composer use

Optional:

• register on Packagist or set up custom Composer repo

Opinions? I can get this done easy, just don't want to bother if there is no interest in adopting it.

[markjaquith]

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?

[markjaquith]

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?

[Rarst]

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.

[Rarst]

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.

[markjaquith]

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?

[markjaquith]

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?

[Rarst]

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:

• dependency is fixed at specific VC revision
• build is performed by VC (multiple VC if we are mixing)
• dependency can only come from VC
• each package using dependency does so independently

With Composer:

• dependency is fixed at specific version or described by version logic (wildcard, range, etc)
• build is performed by composer (which transparently calls VC if needed)
• dependency can come from VC or HTTP download
• if we are building larger project (whole site stack) single copy of dependency is shared between packages that require it

There aren't many Composer-powered plugins for WP around yet. For example I have recently released Laps (composer.json)

[Rarst]

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:

• dependency is fixed at specific VC revision
• build is performed by VC (multiple VC if we are mixing)
• dependency can only come from VC
• each package using dependency does so independently

With Composer:

• dependency is fixed at specific version or described by version logic (wildcard, range, etc)
• build is performed by composer (which transparently calls VC if needed)
• dependency can come from VC or HTTP download
• if we are building larger project (whole site stack) single copy of dependency is shared between packages that require it

There aren't many Composer-powered plugins for WP around yet. For example I have recently released Laps (composer.json)