![]() ![]() ![]() "post-install-cmd" : "Automation\\Events::postInstall" After that, in your project’s composer.json file, ensure that a new namespace called Automation is registered, by having the autoload section include the following: Now let’s bring things closer to home, by looking at an example for Zend Expressive which does largely what the Laravel code does.Ĭreate a new directory, called src/Automation and in there create a new PHP class, called Events.php. In this instance, it ran Composer’s autoloader and called the clearCompiled() method, which clears the cache directories. With the Event object, you can get access to a wide range of information about the environment in which Composer is running, along with configuration details, and so on. Then, the method which is called is a static, which is passed a Composer\EventDispatcher\Event object. So, there’s only minimal effort required to create one. Here, you can see that it has no inheritance hierarchy. If ( file_exists($servicesPath = $laravel -> getCachedServicesPath())) unlink($servicesPath) If ( file_exists($compiledPath = $laravel -> getCachedCompilePath())) unlink($compiledPath) Protected static function clearCompiled() Public static function postInstall( Event $event) Here is a stripped down version of the scripts section which comes with all Laravel projects. Now let’s see how to respond to events which Composer fires, as well as how to create a custom callback in PHP. Responding to Events in The Composer Lifecycle It’s your responsibility to ensure that the commands you wish to execute are present. It will just attempt to do what you’ve asked. Finally upload-coverage runs the coveralls command.Ī word of warning: Composer won’t check if you have the command-line executables installed. Test-coverage calls phpunit specifying that colors are to be displayed and coverage data is to be generated. Here, it calls vendor/bin/codecept passing the run switch to run all of the available unit, functional, and acceptance tests. I’ve modified test from the one that comes with the Skeleton Installer to use Codeception, my preferred testing library. cs-check calls phpcs and cs-fix calls phpcbf.īoth of these are part of the PHP CodeSniffer package. The check command, as we’ve already seen, runs two existing commands: cs and test. You can see that it has six sub-sections. "test-coverage": "phpunit -colors=always -coverage-clover clover.xml", The key is the name of the command, and the value is what to run. In essence, it’s a list of key -> value pairs. The Scripts Sectionīut before we can do that, what does the scripts section look like. I’ve also included a custom one for use explicitly with Expressive projects. I’ve based both on real world examples, taken from the Zend Expressive Skeleton Installer and Laravel projects respectively. The first one will highlight using arbitrary names, and the second will highlight using Composer events. In today’s tutorial, I’m going to take you through examples which highlight both approaches. Or they can use the names of events which Composer fires during its execution process, such as post-root-package-install, pre-install-cmd, and post-package-update. ![]() The commands can be named as you see fit, such as test, clean, deploy and so on. The scripts section of composer.json allows you to set up a range of commands which relate to your project, commands which call command-line executables and PHP callbacks. This isn’t always a good thing though it can be helpful.Īnd in a world we forever have less and less time but are expected to do ever more, this can only be a good thing.ĭisagree with me? Shout at me in the comments. Why leave the language you’re using to create the rest of your application? Stay in the same mindset. What’s more, it’s a tool intimately intertwined with PHP. You don’t have to look as far and wide as you may have before to know: Because you can keep everything in a very tidy, organized, and well-structured way. Why? Because you can bring everything that much closer together. But I see a place for having automation in Composer - though at first I didn’t. Perhaps you think that this is unnecessary, as there is already such a wealth of tools available including Make, Ant, Phing, and so on. If you’ve never heard of this section, it provides a way to automate tasks in your project. Here, in the second part of the series, we’ll look at the scripts section of composer.json. We also looked at some of the switches which can be passed to those commands. In the first part of this series, we started digging into Composer, looking at a range of command line options which Composer provides. Part three covered: How To Use Forked Repositories In Composer.Part one covered: The Composer Command-Line Essentials. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |