Today I’d like to share some nice tools I stumbled upon this year (& the last one, too), & I now use with both pleasure & strong feeling of efficiency.
I present them as a stack that would surely help both newcomers & veterans developers.
Maybe you’ve already heard about some of them, I hope my post will make you discovers some new ones.
First, Composer (http://getcomposer.org), as the de-facto dependency manager of the PHP ecosystem. It’s not a misnomer to call it a widely adopted, quasi mandatory tool & industry standard for PHP libs: In the last months, every new PHP-written lib or app you saw popping up in your Github or Twitter feeds was based on this tool & had a `composer.json` configuration file.
In connection with its Package Manager, Packager.org & wth, say, Github as revision control system, Composer allows you to list & install locally, or update, the tiers PHP libs you’re using. Composer installs them as dependencies in your project, managing them as vendors, with advanced version management features (“Please-keep-me-updated-about-bugfixes-only”, “never ever upgrade”, “use the last stable version” etc.), & it autoloads them inside you project.
Composer is transforming good old PHP in a real open-source community-based development environment, inside which you just focus on coding your own project’s features, using all the ready-to-use libs Packagist offerst you, & therefore stopping reinventing the (squared) wheel.
Who knows, maybe some day we’ll say that Composer & Packagist saved good old PHP from being thrown out of a developer’s window.
Concretly, here are the steps :
1. Create a damn simple `composer.json` file :
In this example, we want to install Monolog, a PHP lib that ends your logs to files, sockets, inboxes, databases and various web services. We’ll install it locally inside our project’s folder.
Here we are targetting the 1.2.* version of monolog. “1.2.*” is a semantic way to number a project’s versions : it is to be read as: “MAJOR.MINOR.PATCH”, where :
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
So with semantic versioning, “dependency hell" no more.
2. Once you’ve determined & settled which version you want to use, download the Composer executable:
$ curl -sS https://getcomposer.org/installer | php
Tip: To make Composer globally accessible on your system, move the resulting composer.phar file to a suitable location, like so:
$ sudo mv composer.phar /usr/local/bin/composer
3. Install the vendors you listed inside you composer.json file:
$ php composer.phar install
Here you are: Monolog is now installed inside a brand new `vendors/` directory, in your project’s root dir.
Composer also creates a PSR-0 autoloader for you to pull the libraries into your code; simple require vendors/autoloader.php in your code to use them :
$log = new Logger('name');
$log->pushHandler(new StreamHandler('path/to/your.log', Logger::WARNING));
If you’re using SVN/GIT/Mercurial, just ignore (cf. .gitignore file) the whole `./vendors` directory, & only add the composer.json file to your version control repo. No need to add & share these vendors : Your teammates will just have to run the `composer install` command to grab them & have them freshly updated (new bugfixes included). The “1.2.*” semantic version annotation allows you to rely on a stable version of your dependency, with bugfixed-only updates.
Here we are with Composer, just check out the doc to discover more from it.
Composer install Vs Composer update
Last but bot least, a nice diagram coming from adamcod.es, to explain the magic trick about the install & update commands and there misunderstood differences:
Tip: `composer.lock` file is to be shared & commited, do not ignore it !
Next post (to write): Bower (the same dependecy manager, for Js!)