I had brought up a similar question on StackOverflow, but it hasn't gotten much traction because of a lack of understanding of Drupal, I think.
The issue we are experiencing happens when a developer removes an extension from Drupal then removes the composer package as well, and checks all these changes into git. Subsequently, all other developers are unable to run the typical sequence of
composer install followed by
drush cim in their development environments because doing so attempts to uninstall the extension, which can't be done because the composer package has been removed. This also happens when switching back to
master from a feature branch that includes a package and installed module.
What I was hoping for was a version of
composer install that does not uninstall any packages removed from
composer.json. But such an option does not appear to exist. My proposed resolution was to filter the
composer install output for lines indicating a package was uninstalled, then re-install those packages, run
drush cim, then run
composer install once again. Overall an ugly workflow.
It has been suggested to run
drush cim followed by
composer install, but that breaks on the addition of new modules.
Does anyone have a more elegant workflow that can handle the above situation and also handle cases where modules are added and/or other configuration changes are made?
It has been suggested that this is a duplicate of the related post Development with git branches/ gitflow and new modules which deals with the different issue of extension database tables getting installed twice when switching between branches, which is more of a drupal core issue than a composer issue. Granted, the unsatisfactory fix proposed for that issue (syncing to a database image) could work here, but it would be equally unsatisfactory and unnecessarily time consuming for large databases.