Composer is not just a package installer. In a Drupal or custom PHP project, it is part of your delivery system: it defines what gets deployed, which versions your team shares, and how predictable your updates are. For business owners, operations leads, and agency teams, that matters because dependency drift quickly turns into missed release windows, fragile staging environments, and emergency fixes that are hard to reproduce. The goal is simple: make Composer part of a repeatable workflow, not something somebody runs only after a site starts failing.
Install Composer without root when you can
The old habit of piping the installer straight into PHP and relying on root access is no longer the best default. Composer’s current documentation recommends downloading the installer, verifying it, and then placing the binary somewhere on your PATH. If you do not need a system-wide install, a user-writable path such as ~/.local/bin is usually the cleaner operational choice.
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
# Verify against the current SHA-384 published on getcomposer.org/download
php composer-setup.php --install-dir="$HOME/.local/bin" --filename=composer
php -r "unlink('composer-setup.php');"This matters for security as well as convenience. Composer can execute plugins and scripts during install and update, so running it as root should be the exception, not the habit. If you are evaluating untrusted code, isolate it in a container rather than giving it elevated access on a live box.
Start Drupal projects the current way
If you are creating a new Drupal project, use the official drupal/recommended-project template. That replaces the much older drupal-composer/drupal-project:8.x-dev approach from the original note. The recommended template puts the public web root in /web and keeps vendor and Composer files outside the document root, which is the structure most teams want for cleaner hosting and safer deployments.
composer create-project drupal/recommended-project my_site_nameIf you need to adjust the web root before dependencies are installed, start with --no-install, make the change in composer.json, and then install.
composer create-project --no-install drupal/recommended-project my_site_name
cd my_site_name
composer installThat is a small detail, but it saves rework later when an agency inherits the project, moves hosting, or needs a more disciplined deployment layout.
Check versions before you require anything
One useful tip from the original article still holds up: inspect package availability before you pull a module or library into a production project. That is especially important when a package offers stable tags, dev branches, and prerelease builds at the same time.
composer show drupal/video_filter --available
composer show drupal/video_filter --allIf you are watching upgrade pressure across a Drupal estate, a few more commands deserve regular use:
composer outdated
composer outdated 'drupal/*'
composer audit
composer validateoutdated shows what is lagging behind, audit checks installed packages against security and dependency policy issues, and validate catches broken or stale composer.json and composer.lock state before it reaches CI or production. For operations teams, those commands are cheap risk-reduction.
Add packages deliberately
Multiple package installs are still perfectly valid, and they are often cleaner when a feature depends on more than one module. Composer handles that well.
composer require drupal/pathauto drupal/metatag
composer require --dev drupal/develThe more important habit is how packages are added. Use Composer commands instead of editing dependency files by hand or dropping code into the repository. That keeps the lock file accurate, makes changes reviewable, and reduces the “works on my machine” problem when another developer or hosting environment runs the same build.
Debug conflicts instead of guessing
When Composer refuses an update, random constraint edits are usually the slowest possible path. Current Composer tooling is much better than that. Start by asking why a package is present and what blocks the version you want.
composer why -t drupal/file_mdm_exif
composer why-not drush/drush 14.0.0
composer prohibits php 8.3composer why shows what depends on a package. why-not and prohibits show what is blocking a target version or even a platform upgrade such as a newer PHP release. In practice, that is the difference between a ten-minute diagnosis and an afternoon of trial and error.
Keep Drush inside the project
The older advice about deleting vendor/drush by hand is not a good long-term fix. Current Drush guidance is straightforward: Drupal sites should be Composer-managed, Drush should be a dependency of that project, and you should run it from the project context.
composer require drush/drush
vendor/bin/drush statusIf a Drush update causes bootstrap issues, fix it through Composer so the dependency graph and lock file stay honest.
composer remove drush/drush
composer require drush/drush:^13Use the correct major version for the Drupal version you actually run. Current Drush compatibility guidance lists Drush 13 as the supported line for Drupal 10.2+ and Drush 14 for Drupal 11.3+. If your team manages several sites, pinning the major version is a simple way to avoid surprise upgrades in the middle of a release cycle.
If the same team works in one codebase every day, adding ./vendor/bin to the shell PATH is reasonable. The key point is that Drush stays tied to the project, not to whatever global install happens to live on a laptop or server.
A practical baseline
A healthy Composer workflow is not fancy. New Drupal projects start from the right template. Packages are added intentionally. Version conflicts are diagnosed with Composer’s own tools. Drush lives in the project and matches the Drupal version in play. That is the kind of setup that makes handovers easier, upgrades safer, and deployments more predictable.
If your stack needs that kind of cleanup or you want a steadier delivery process around Drupal, Composer, and hosting decisions, Greg can help bring structure to it without turning it into bureaucracy.
Need help with this kind of work?
Need a steadier Composer and Drupal delivery process? Get in touch with Greg.