For open source projects I’m involved with, I developed the habit to define and document the steady growing amount of repository and build utilities via scripts. Having Composer available makes it trivial to define aliases or shortcuts for complex and hard to remember CLI calls. It also lowers the barrier for contributors to start using these tools while helping out with fixing bugs or providing new features. Finally they’re also simplifying build by stashing away complexity.

Defining Composer scripts

If you’ve already defined or worked with Composer scripts or even their npm equivalents you can skip this section, otherwise the next code snippet allows you to study how to define these. The here defined Composer scripts range from simple CLI commands with set options (e.g. the test-with-coverage script) to more complex build utility tools (i.e. the -version-guard script) which are extracted into specific CLI commands to avoid cluttering up the composer.json or even the .travis.yml.

composer.json
{
"scripts": {
"test": "phpunit",
"test-with-coverage": "phpunit --coverage-html coverage-reports",
"cs-fix": "php-cs-fixer fix . -vv || true",
"cs-lint": "php-cs-fixer fix --diff --stop-on-violation --verbose --dry-run",
"configure-commit-template": "git config --add commit.template .gitmessage",
"application-version-guard": "php bin/application-version --verify-tag-match"
}
}

Describing Composer scripts

Since Composer 1.6.0 it’s possible to set custom script descriptions via the scripts-descriptions element like shown next. It’s to point out here that the name of a description has to match the name of a defined custom Composer script to be recognised at runtime. On another note it’s to mention that the description should be worded in simple present to align with the other Composer command descriptions.

composer.json
{
"scripts-descriptions": {
"test": "Runs all tests.",
"test-with-coverage": "Runs all tests and measures code coverage.",
"cs-fix": "Fixes coding standard violations.",
"cs-lint": "Checks for coding standard violations.",
"configure-commit-template": "Configures a local commit message template.",
"application-version-guard": "Checks that the application version matches the given Git tag."
},
"scripts": {
"test": "phpunit",
"test-with-coverage": "phpunit --coverage-html coverage-reports",
"cs-fix": "php-cs-fixer fix . -vv || true",
"cs-lint": "php-cs-fixer fix --diff --stop-on-violation --verbose --dry-run",
"configure-commit-template": "git config --add commit.template .gitmessage",
"application-version-guard": "php bin/application-version --verify-tag-match"
}
}

Now when running $ composer via the terminal the descriptions of defined custom scripts will show up sorted in into the list of available commands, which makes it very hard to spot the Composer scripts of the package at hand. Luckily Composer scripts can also be namespaced.

Namespacing Composer scripts

To namespace (i.e. some-namespace) the custom Composer scripts for any given package define the script names with a namespace prefix as shown next. As the chances are very high that you will be using the one or other Composer script several times, while working on the package, it’s recommended to use a short namespace like in the range from two to four characters.

composer.json
{
"scripts": {
"some-namespace:test": "phpunit",
"some-namespace:test-with-coverage": "phpunit --coverage-html coverage-reports",
"some-namespace:cs-fix": "php-cs-fixer fix . -vv || true",
"some-namespace:cs-lint": "php-cs-fixer fix --diff --stop-on-violation --verbose --dry-run",
"some-namespace:configure-commit-template": "git config --add commit.template .gitmessage",
"some-namespace:application-version-guard": "php bin/application-version --verify-tag-match"
}
}

Now this time when running “/>

Truncated by Planet PHP, read more at the original (another 1236 bytes)



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here