>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2753825. --> Reported by: [Mixologic](https://www.drupal.org/user/391689) >>> <p>So we've been running into a documentation/expectation issue with regards to what is supposed to happen when a user executes <code>composer require drupal/projectname</code></p> <p>An example is commmerce. If a user does a <code>composer require drupal/commerce</code>, it will download the commerce project, but it currently will *not* download the module dependencies expressed in the submodules like commerce_order and commerce_payment. bojanz has added those requires to the composer.json, but they are currently being ignored while the composer facade has postponed that behavior on <a href="https://www.drupal.org/node/2746737">https://www.drupal.org/node/2746737</a>. In order for a user to get the *other* drupal module dependencies required by commerce_order, they would need to <code>composer require drupal/commerce_order</code>, which has commerce_orders' dependencies expressed, which in this case are drupal/state_machine and drupal/profile</p> <p>So the question is if one executes <code>composer require drupal/projectname</code>, Should the project metadata have all of the requirements of its components listed at the root level? If a submodule has a dependency on a third party lib from packagist, should that require be bubbled up to the project level? </p> <p>One problem with that is that there are some projects that act as containers for groups of related submodules, but that often do not require all modules - cod_support is a good example. If we pulled in all optional submodule dependencies, we end up with 103 modules, not counting how many modules each of those might have (cod_support has a cod_commerce module which has commerce as a dependency). So, the number of excess downloaded modules could get out of hand - particularly if you only needed the cod_support module for cod_registration and not commerce.</p> <p>Im leaning towards a "let the maintainer exercise control" vs a "load all submodules, and their dependencies, and their 3rd party libs always, just in case they enable an optional module". That way if a maintainer thinks an end user should have all the optional dependencies, they can express that in the root composer.json of the project. Otherwise the assumption is that an end user needs to <code>composer require drupal/submodule</code> to get dependencies of optional submodules.</p> <p>What I plan to do then, is to handle the deprecated versioning in modules listed in <a href="https://www.drupal.org/node/2746737">https://www.drupal.org/node/2746737</a>, and go ahead and merge all the requirements from a composer.json if it exists.</p>