Problem/Motivation
I ran into a issue today testing using a recipe in place of an install profile. Everything appears to have gone fine, except I cannot update any modules that were required by the recipes composer.json file.
Steps to reproduce
Create site with core/recommended-project template via composer.
Require my test recipe via Composer.
Now that that recipe is required and listed in the root composer.json dependency, composer is now adhering to the version constraints of that recipes composer.json.
That means if an update comes along and Pathauto gets a 2.0 version, I cannot run 'composer update drupal/pathauto' or 'composer require drupal/pathauto:^2.0' because it will error with a conflict. Using -W does not get around this either. This will make mixing/matching recipes tough and or 'breaking free' of an install profile style recipe when you need to perform module updates.
Proposed resolution
Following whats been done here: http://fabien.potencier.org/symfony4-unpack-the-packs.html
It would be nice to see a similar behavior of these 'unpacking' to the root composer.json so it behaves closer to a traditional composer managed Drupal project. Otherwise, site owners will be locked into whatever recipes like these had at the time they were downloaded and applied. If the recipe is abandoned, won't this make updating those modules not possible?
Similarly, if you want to remove a recipe from a project to prevent any accidents in a mature project, composer should not try to remove the dependencies of that project from you. That should be an explicit action by the site owner / developer.
Remaining tasks
- Add test coverage of the new composer command
composer drupal:unpack "recipe-package-name" - Add test coverage of unpacking a recipe with package manager
- Check existing test coverage to make sure it is good
- Write a change record
User interface changes
tbd
API changes
tbd
Data model changes
tbd