Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Composer integration has always been difficult, because we always relied on modules being places in specific directories for discovery. In an abstract sense, this means packages must be merged in order to build the codebase. When using build tools that are not specific to Drupal this requirement proves to be difficult to support. Composer, for instance, never merges packages and puts all of them in the same place without any hierarchy. The drawback of this approach is that Drupal cannot find the available extensions, and that workarounds are needed to support Drupal's own discovery mechanisms, such as composer/installers and wikimedia/composer-merge-plugin.
Proposed resolution
Because Drupal 8 ships with ExtensionDiscovery, which is essentially a single point of discovery for all extensions, we have come to a point where it no longer matters where extensions are located, as long as this single discovery method is capable of finding them.
Given this assumption, we can write extension discovery solutions for different build tools. The default one that ships with Drupal finds extensions in the directories we have been used to for years, but another, separate one, can be written to find extensions that were installed through Composer. If another build tool becomes popular in a few years, a discovery mechanism can be written for that as well, without changing any of Drupal's internals. This way, we do not depend on any specific build tool, yet keep the potential to integrate with all of them.
Remaining tasks
T.B.D.
User interface changes
None.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | drupal_2701253_2.patch | 95.51 KB | Xano |
Comments
Comment #2
XanoAfter applying this patch, run
composer update.The patch extends the existing discovery method with the ability to scan for extensions in installed Composer packages. To test, run
composer require drupal/plugin:*and verify that it is installed in./vendor/drupal/plugininstead of./modules. This patch does not introduce swappable extension discovery, nor does it scan for submodules. I also need to clean upcomposer.lock.Comment #3
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedThe vendor folder is not web accessible by default, but drupal module contain assets (js, css, libs) and these files are stored inside of the module. I don't see how this should work. I know Symfony uses Assetic to solve this problem.
Comment #4
dawehnerGood point! http://docs.puli.io/en/latest/ also has an entire ecosystem to deal with that problem.
Comment #5
XanoOther types of Composer packages can come with assets as well. #4 gave an example of that. Does #3 mean that such packages are broken then?
Comment #6
dawehner@xano
Of course they are already, but by moving modules to that, you make it realistic in a really common case. This is one of the things where we have implicit assumptions about where we think modules/themes are.
Comment #7
dawehnerLet's make it more clear