Two fl avours: ini or yaml (!) Site built with exact versions of: • Core • Projects (modules, themes) • Libraries Support for just-in-time patching. Support for git, svn, bzr, copy, etc downloads. drush make-generate project.make
lots of new features • not backwards compatible • y - minor version • some new features • backwards compatible • z - patch version • bug fi xes only Drupal core: 8.6.2
7 PHP extensions requirements Composer patches library + patch to preserve-paths Composer preserve paths library (to preserve sites/all/*) -> in case anything happens your fi les are in ~/.composer/cache/preserve-paths/ Correct installer paths con fi guration Correct preserve-paths con fi guration
stability dev --no-interaction Drupal 7: composer create-project drupal-composer/drupal-project:7.x-dev some-dir -- stability dev --no-interaction Word of caution: "con fi g": { "platform": {"php": "5.5.9"} },
During deployment: composer install • Add new modules (do not manually edit composer.json) composer require drupal/project “^1.0” --update-with-dependencies • Finally commit BOTH composer.json and composer.lock
--format=composer > composer.json Does not convert libraries. See the README.md of drupal-project/7.x on how to con fi gure. Some post-convert enhancements (from d-p/7.x composer.json): • Add scaffolding (autoload and scripts section), and the following requires: composer/semver, drupal/composer_autoloader, symfony/ fi lesystem web fl o/drupal- fi nder. • Add the patch to cweagans/composer-patches
/web/sites/all/themes/contrib/ /web/sites/all/libraries/ # Ignore Drupal 7 core fi les. /web/* !/web/*/ /web/includes/ # Ignore con fi guration fi les that may contain sensitive information. /web/sites/*/*.settings.php /web/sites/*/settings*.php # Ignore paths that contain user-generated content. /web/sites/*/ fi les /web/sites/*/private
• commit composer.json AND composer.lock • use semantic versions • use composer as a development tool • DON’T • run “composer update” naked, unless you plan to test everything that is updated • commit /vendor nor any 3rd party code (from drupal.org or libraries) • use composer as a deployment tool
dependency. • Are you ready to test the entire functionality affected by all the modules? • However: don’t fall behind. Update everything and retest site completely, from time to time.
requests should just be the changes your team made • Pull requests should not include the past 6 months of changes to Drupal core, Symfony, etc. • Do not use git for deployment. • Trust the Internet availability.
• Do the work • Rebase to latest version of parent branch git rebase branch • Export con fi g drush cex • Check changes git diff • Add fi les and commit git add fi le1 … fi len ; git commit -m “TKT-42: 6 times 9 in base 13” • Create pull request in github/gitlab/bitbucket • Merge the feature branch