- Issue created by @ashrafabed
Composer has the option to prevent download of conflicting modules using its "conflict" property. Some modules make use of this, such as acquia_migrate ( https://www.drupal.org/project/acquia_migrate → ), which prevents downloading migrate_tools (see https://git.drupalcode.org/project/acquia_migrate/-/blob/1.8.x/composer.... ).
In a multisite project I'm working on, we want to use acquia_migrate for some projects and migrate_tools for others (in the same codebase). Because the conflict is logged at the composer level, we can't do that using standard approaches. And if we *do* bypass the composer restriction, then Drupal will let us enable both modules, which, in this case, is undesirable.
Because Drupal has support for multisites, I believe conflicting Drupal projects should, generally, be recorded at the Drupal level - not at the composer level.
Try to download acquia_migrate and migrate_tools using Composer in the same Drupal codebase.
Add support for a "conflict" (or conflicts, plural for consistency with "dependencies"?) property to Drupal .info.yml files.
If a project A is enabled/installed, and a user attempts to enable/install project B which is listed in project A's "conflict" section, Drupal will prevent project B's installation. The same way Drupal would prevent installation of a module if it does not have appropriate core_version_requirement constraints.
Likewise, if project B is enabled/installed, and a user attempts to enable/install project A while project A lists project B in project A's "conflict" section, Drupal will prevent project A's installation.
Implement the proposed resolution.
An error message explaining why a module can not be enabled if a conflicting module is already enabled.
Added support for "conflict" property to *.info.yml.
N/A
TBD
Active
10.1 ✨