Recently I’m considering a not-so-common Composer feature: commands (scripts).

Composer already provides some hooks, you can find the list of provided hooks here: getcomposer.org/doc/articles/scripts.md#event-names

These hooks you see aren’t the same commands I mean in this article, because can’t be invoked using composer post-install-cmd, I’m going to list some scripts I found useful, but before let me explain some reasons why I think they should be included in your composer.json.

## Questions

People don’t know how you do it.

To solve the problem about how it should be done, usually, OSS developers share a CONTRIBUTING.md file containing instructions about the requirements of their pull requests. This is generally enough, but all the instructions listed are always the same on every environment, so why don’t encapsulate them in a single istruction?

How should I test it?

PHPUnit, Behat, PhpSpec, etc… there are lot of libraries to execute tests out there, before submitting something how should I test my changes?

What should I do after installation?

Ok, I’ve installed a fork of symfony/symfony-standard including some test-only changes, how can I execute these changes on my continuous integration system without calling them also on development and production?

Prevent ambiguity.

Do you know that a developer could have 3 PHPUnit versions on his/her environment?

Lets say he/she has:

• PHPUnit v3 at /usr/local/bin/phpunit
• PHPUnit v4 at ~/.composer/vendor/bin/phpunit
• PHPUnit v5 at [project]/vendor/bin/phpunit

Which version should be used? Can these versions be used without problems or some of them aren’t compatible with my codebase?

The developer probably will use just the phpunit command, which of them will be executed?

## Commands

### composer test

Already introduced by github.com/thephpleague/skeleton here, using this command you don’t need to worry about which version of your testing tool is used nor where it is.

Note: Composer’s bin-dir is pushed on top of the PATH so that binaries of dependencies are easily accessible as CLI commands when writing scripts.

Do you need to execute a test before another (you can’t write a dependency between phpunit and behat)? For example if you don’t want execute functional tests before having checked that every unitary test is executed correctly, and before of all a PSR-2 coding style is strictly required.

{
"scripts": {
"test": [
"phpcs src --standard=psr2 -spn",
"phpunit",
"behat"
]
}
}


What’s the version used?

The priority is given to [project]/vendor/bin/phpunit, but if it’s not included (for example if you’re testing the prod mode locally) than depending on your \$PATH ~/.composer/vendor/bin/phpunit or /usr/local/bin/phpunit will have the priority without changing your codebase!

### composer compile

Already introduced by Heroku here this command allows you to execute a set of steps (or a single script) without forcing these commands on every package install or update.

An example of its usage? Ok, let’s say we are installing a bundle on a Symfony 2 app, adding a app/console cache:clear will always give an error if executed right after the install or the update, so we can add a command like this:

{
"scripts": {
"compile": [
"app/console -n cache:clear",
"app/console -n assets:install"
]
}
}


The -n option is usually not required, but for security I always add it.

Once you’ve finished the installation and configuration of your bundle, just run the composer compile to be sure that’s installed completely.

### composer check-style

A lot of projects started using coding standards during last years, but which tools? And which options? The order of them?

As always a simple command can solve this doubt:

{
"scripts": {
"check-style": [
"php-cs-fixer fix --config-file=.php_cs",
"php-formatter formatter:use:sort src"
]
}
}