Composer became the de facto standard for managing libraries and dependencies in the PHP world. With the new Drupal 8 paradigms dealing with Composer has reached a higher level. This presentation describes how Composer will influence Sitebuilders and Drupal developers life. The presentation was held at the DrupalCamp Lofoten 2016. Video: https://youtu.be/Kva85G4W2B4?t=2170
3. See everything as a library!
generic libraries hosted outside of the drupal
ecosystem
attracts Drupal and non-drupal developers
Especially for 3rd-party integrations
drupal.module
drupal.module
Library 1
Library 2
Drupal 7
5. Advantages of the library approach
Hop of the island
A bigger crowd to create sustainable
solutions
Less migration work on core upgrades
more agile development process
easy update with `composer update`
7. Disadvantages of the library approach
Code is spread out
Centralization benefit of drupal.org gets lost
Multisite troubles and risks
Platform needs to be seen as a whole
11. The contrib composer workflow
download your module as usual
always! resolve your composer
dependencies before installing a new
module
enable the module
13. Composer Manager
Offers the `composer drupal-update`
command
own report page in admin UI
it acts globally on the platform
avoid dependencies on that module
might be deprecated in mid-term
15. Composer and Ægir
currently no composer support
site migrations will fail
Workaround:
copy the site manually
resolve dependencies
perform the migration
17. Outside of the box
The composer workflow could extended
even more
Using composer.json instead of makes
`drush make` -> composer.json
composer create-project drupal-composer/drupal-
project:~8.1 drupal --stability dev --no-
interaction
`drush dl migrate_tools --dev`
composer require drupal/migrate_plus 8.1.*@dev
move to OOP, adoption of symfony, drupal opens its own ecosystem to the world
change of mind for drupal developers
modules are not only interacting with Drupal APIs, but using a library approach of development
fundamental parts of the module are encapsulated in a component, that can be fetched from other resources, mostly git hosting platforms such as github
D8 module only binds the library to the D8 APIs
especially 3rd-party but also the other way around
commerce guys, being one of the biggest ambassadors
Hop-of the island: something even Martin, living at the Lofoten, needs to from time to time
it invokes a huge developer community
more agility - more updates - will lead to better systems
less migration work: libraries are more independet, you only need to change the interfaces
the source code will be much more distributed
all the benefits of centralized issue queues in drupal get lost
at ramsalt we’re using multisites in a extended way - we cannot treat every site within a platform as being quite isolated
Platform needs to be seen as a whole -> take care of other multisites in the same platform
- Want to do the proof, that composer will be influence your developer life
- even in my first D8 live installation for a client i use a couple of modules
- even a module with a
- you can imagine increasing the list when you have a really complex site
download your module: preferable with drush
resolve composer dependencies: some modules are not properly checking the requirements and installing the module migh lead to WSOD -> even drush uninstall might fail -> you’ll have time to explore the D8 database to fix the site
avoid dependencies on that module
some maintainers started with it
but it limits the composer workflow to the only one way
smart overview page, that lists the composer libraries, compareable to that was the library module mostly for js libraries does in d7
it seems that the composer_manager workflow will deprecates in mid-term and will be replaced for a composer only strategy
site migrations will fail: because of missing dependencies in the new platform