Composer & friends: herding libraries with your robot sheepdog(s)

Composer is suddenly everywhere in the Drupal world.

With the adoption of the Symfony framework, Drupal is now able to make use of the wider PHP community's standard tools. Composer is one of these, and it's becoming increasingly common for projects to use composer to install both Drupal core and contrib modules and themes. But there's no consensus on how to best manage non-PHP libraries, and how to make sense of the wildly variable file structures they use. There is currently no obvious best-practice way of keeping non-PHP libraries up-to-date within a Drupal project.

This session will discuss the uses of Composer to install Drupal core and contrib modules, ask how (and whether!) to use it instead of (or in conjunction with) standard front-end package managers and task-runners to install and update libraries in themes and modules, and show how its capabilities dovetail with other package managers and task-runners (such as NPM, Bower, Grunt and others) in the front-end world. We'll also touch on the definition of libraries in D8 modules and themes.

Finally, we'll explore the possibility (and practicality!) of creating and using a PHP-only stack for managing all Drupal core, contrib, and front-end packages, and for running all tasks.

You'll leave this session with an appreciation of how Composer is routinely used, how it can be used with (or instead of) other package managers, some of the problems surrounding the maintenance of non-PHP libraries, and how Composer and your other robot friends can help you bring those libraries back into the fold.