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.

  • If I read this right, what they should do when starting new work is pull changes and sync their database to the prod/staging db. It will avert instances like this, where the remote instance is properly updated but X people downstream suddenly have the carpet yanked out from under them. – Kevin Nov 18 '19 at 14:58
  • I assume the same problem happening when adding these changes to live too? As I'm guessing the same commands will be run there – Leigh Nov 18 '19 at 15:09
  • @Kevin - we try to avoid database syncing as much as possible since it's such a time sink. – Mike Godin Nov 18 '19 at 15:16
  • @Leigh -- you are correct the same issue would happen if a module were removed from live -- but fortunately that's a less common occurrence than for example returning to master from a feature branch that contains a module. – Mike Godin Nov 18 '19 at 15:17

Browse other questions tagged or ask your own question.