Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.In parallel with the discussions surrounding how to integrate a composer based workflow into drupal and its modules, there are infrastructure requirements and impacts that should be considered/discussed/resolved in order to support a composer based workflow for the drupal ecosystem.
Some questions that need to be discussed/clarified in using packagist as our dependency metadata resolution repository.
- What impact will hosting a project the size of drupal have on packagist infrastructure? Can they handle whatever load we're going to send, and is there a cost associated with that?
- What metrics will we be able to collect from packagist?
- What does drupal.org need to do to get first class citizenship like github and bitbucket have for our git repos?
- How are security issues handled with packagist? Will the security team be able to unpublish insecure modules?
- Who owns/manages 'vendor' account at packagist?
- Would this have an impact on updates and the drupal.org's update system? i.e. what happens when a module checks in a composer.lock file with insecure versions?
- How are distributions/install profiles affected by something like this?
- Is packaging/tarballs still needed for d8+ if we go to composer based workflow?
| Order | Issue | Assignment | Comments |
|---|---|---|---|
| 1 | #1503234: Process Composer components when building Drupal core | who? | Composer for tarball |
| 2 | #2622462: Make sure packaging plays nice with GitHub api limits | who? | Api limits |
| 3 | #2622474: Testbots need some kind of composer cache | who? | Composer for testing |
| 4 | #2622394: Use composer for dependency resolution when running tests | who? | Composer for testing |
| 5 | #2622494: The updates process should alert about new versions in composer dependencies | who? | Depedency alerting |
| 6 | #2622482: Update download stats processing for Composer | who? | Stats |
| 7 | #2622466: Packaging should create a composer.lock file for distributions | who? | R&D - can we support distros this way? |
| 8 | [#] R&D How to support multi-sites? | who? | R&D |
| 9 | #2352091: Create (and maintain) a subtree split of Drupal core | who? | Eventually, subtree split core components |
| 10 | #2622470: Explore Toran Proxy for release packages | who? | R&D |
Comments
Comment #1
MixologicIn order to keep packagist up to date, we'll need something that connects our git infra to packagist.
Comment #2
MixologicWe may host drupalesque php libraries ourselves.
Comment #3
MixologicWe may want to allow use of "drupal core" - the codebase, independently of drupal, the product (with the front controllers, htaccess, and other structure). To do this we'll need to offer a subtree split of drupal, much like other projects offer.
Comment #4
hestenetComment #5
hestenetComment #6
drummComment #7
hestenetCore issue #3075954: Remove duplicate scaffold files is postponed on this issue.
Comment #8
hestenetComment #9
MixologicThis meta is sorely out of date, and not sure what purpose it serves. Im going to close it in favor of either new metas, or separate issues.
Comment #10
gregglesWhich is kind of great news!
Thanks to everyone for a lot of great work that has really helped in this area. Increasing our use of Composer has been a great improvement to productivity and repeatability for me and my coworkers. It's very appreciated.