Note to self: когда есть задача выключить из проекта тот или иной контриб-модуль, никогда не надо в этой же задаче требовать убрать сам код модуля из проекта.

На примере Drupal: во всех деплой-скриптах, что мне доводилось видеть или писать, `composer install` (установка/обновление/удаление зависимостей) всегда идет первее `drush updb` (миграции БД) и `drush cim` (импорт загруженной из гита конфигурации). И это разумно в большинстве случаев: сначала при деплое мы тянем из интернета новые зависимости, затем запускаем миграции БД, требуемые этими зависимостями, затем применяем конфиг для этих зависимостей, включая yml-файлы с настройками нового модуля.

Однако при удалении модуля всё происходит наоборот: сначала нам нужно применить конфиг, в котором модуль «выключается» из системы, при этом будут удалены yml с его настройками, а также вызваны нужные обратные миграции БД. И только потом уже нам нужно вызвать `composer install` чтобы композер заметил отсутствие модуля в зависимостях и удалил его из кода.

Поэтому если мы единым мердж реквестом подадим отключение модуля (т.е. конфиг в котором модуль отключен) и удаление его из кодовой базы (удаление зависимости в `composer.json` например), то результатом деплоя будет ошибка. Поскольку скрипт сначала удалит кодовую базу, а потом уже попытается выполнить *уже удаленный* код, связанный с деинсталляцией. В результате деплой потребуется чинить вручную и тривиальная задача потребует времени в два раза больше нужного. Это как минимум, а если у нас скажем мультисайтинг с одной кодовой базы на 50 инстансов, вручную чинить уже вообще не захочется.

В общем, вместо требования удалить отключаемый модуль сразу из кодовой базы лучше время от времени создавать maintenance-задачу по удалению из списка зависимостей неиспользуемых и уже ранее отключенных библиотек.