Composer Workflows for Modern Drupal Projects

Treat both Composer files as code

The manifest expresses intent; the lock file records the solved dependency graph. Review both. Production should run composer install --no-dev, never resolve a new graph with composer update.

Update with a defined scope

Inspect outdated packages and advisories, back up, update the intended Drupal packages with dependencies, run database updates, rebuild caches, export configuration changes, and test as anonymous and authenticated users.

Use patches as temporary debt

Document why a patch exists, its upstream issue, and removal criteria. Prefer maintained releases and keep version constraints broad enough for security patches but narrow enough to communicate supported majors.

Working example

composer outdated "drupal/*"
composer audit
composer update "drupal/core-*" --with-all-dependencies
drush updatedb -y
drush cache:rebuild
drush config:export --diff

Separate resolution from installation

composer update decides which package versions satisfy the project's constraints. That decision belongs in development or CI where the resulting composer.lock can be reviewed and tested. composer install follows the already-reviewed lock file and is therefore the appropriate operation for deployment environments.

This separation is especially important in Drupal because a dependency update may also change scaffold files, database update hooks, default configuration, or compatibility with contributed modules.

Treat database and configuration changes as part of the update

A successful Composer command does not finish a Drupal update. Locally, I run database updates, rebuild caches, inspect configuration status, and export configuration only when the update actually changed deployable configuration. That exported configuration is reviewed with the code and lock file.

On the server, the flow is intentionally different: install the reviewed lock file, run database updates, import the repository-owned configuration, rebuild caches, and run deploy hooks. Production should not export configuration back into the repository.

Composer Scaffold is also part of the dependency model

Files such as Drupal's .htaccess, robots.txt, and example settings files can be generated by Composer Scaffold. Project-specific changes to scaffold-owned files should be represented through reproducible mappings or other intentional project configuration rather than edited and forgotten.

That prevents a routine core update from silently replacing behavior the project depended on.

Keep the rollback unit coherent

The code commit, lock file, configuration export, and required database transition describe one release. Treating them as one reviewed unit makes it much easier to understand what should be restored or forward-fixed when a deployment fails.