TL;DR

If you want to support Composer, adding a composer.json is better then just let WPackagist create a package for you.

There are several reasons, no one is really important, but considering that to create a composer.json does not require much effort, it probably worth it.

composer.json Benefits

Below a non-exhaustive list of benefits of using composer.json.

Developer friendly

When you require a package, Composer looks into repositories to find that specific package. Packagist and WPackagist are 2 repositories.

The difference is that Packagist is always parsed by Composer, while WPackagist have to be manually added to the project composer.json.

To require a plugin on Packagist you need a single line in composer.json:

"require": {
    "your-name/your-plugin-name":"1.*",
}

To require a plugin on WPackagist you need to also configure repositories:

"repositories":[
    {
        "type":"composer",
        "url":"http://wpackagist.org"
    }
],
"require": {
    "your-name/your-plugin-name":"1.*",
}

This is also relevant when using command line, see

composer create-project your-name/your-plugin-name

VS

composer create-project wpackagist-plugin/your-plugin-name --repository-url=http://wpackagist.org

Performance

When a project contains more repositories, Composer pings all of them to find information about packages.

So adding WPackagist repository, slows down installation. Also consider that all the servers can be down, for any reson. It happen to much bigger companies than the one behind WPackagist, so every repository you add, it is an additional possible point of failure.

Configuration

On of the advantages of having a composer.json is that you can configure the way Composer will fetch your plugin.

For example, you can use configure the package name in the name property, instead of letting WPackagist create the package name for you.

Moreover there are a lot of configuration that can be done in composer.json, just some few examples:

• you can use the branch-alias setting to improve the compatibility of development version of the plugin
• even if you have no dependencies, you can use the require setting to set a minimum PHP version,
• the conflict setting let you explicit inform about conflicting packages…

and so on.

Ownership awareness

When you require a plugin from WPackagist the “vendor” part of the package name is always wpackagist-plugin.

So people will require you plugin like:

"require": {
    "wpackagist-plugin/your-plugin-name":"1.*",
}

If you put the plugin on packagist, you can use your own vendor prefix, and I think is better for marketing:

"require": {
    "your-name/your-plugin-name":"1.*",
}

Autoload

Composer provide autoload for packages. If you decide to use Composer, you can benefit of it. However, considering that you are shipping your plugin to official repo you need to take into account that the majority of your user will probably install your plugin not using Composer. It means that you have to possibilities:

• ship the “vendor” folder (that contains the autoload) insider your plugin folder in the official repo
• make use of a custom autoloader or a manual loading mechanism in case the plugin is used without Composer.

The second possibility is mentioned only because your plugin has no dependencies handled by Composer, otherwise ship vendor folder is the only possibility to make your plugin work without Composer, but is not issue-free: when different plugins are installed with embedded vendor folder there is the possibility of version conflicts if different plugins ships different version of same package.

Explicit Composer support

By adding composer.json you make people know that you explicitly support Composer. For example, when I search for a plugin, to find a composer.json in the plugin folder is a big plus for me, as I tend to don’t use plugins that don’t do that.

Moreover, there are tools that target plugin explictly supporting Composer.

For example, I have a script that prevents automatic updates for plugin / themes that have a composer.json.