Composer Commands

composer commands cheatsheet.

Require, install, update and autoload — the Composer commands you use every day. Tap to copy.

Install & init
composer initCreate a composer.json interactively
composer installInstall dependencies from composer.lock
composer install --no-devInstall without dev dependencies (production)
composer create-project <pkg> <dir>Scaffold a new project from a package
Dependencies
composer require <vendor/pkg>Add a package and update composer.json
composer require --dev <pkg>Add a package as a dev dependency
composer remove <pkg>Remove a package and its config
composer updateUpdate all packages to latest allowed versions
composer update <pkg>Update a single package
Autoload & scripts
composer dump-autoloadRegenerate the autoloader files
composer dump-autoload -oRegenerate an optimized autoloader
composer run-script <name>Run a script defined in composer.json
composer exec <cmd>Run a vendor binary from vendor/bin
Info & maintenance
composer showList installed packages
composer outdatedShow packages with newer versions available
composer why <pkg>Show what depends on a package
composer validateValidate composer.json and composer.lock
composer diagnoseCheck the system for common problems
Global & self
composer global require <pkg>Install a package globally
composer self-updateUpdate Composer to the latest version
composer clear-cacheClear Composer's package cache
composer --versionShow the installed Composer version

What Composer actually does

Composer is the dependency manager for PHP, and almost every modern PHP project leans on it for two jobs: pulling in libraries other people wrote, and wiring up autoloading so those classes just work. The file at the centre of it all is composer.json, which lists your dependencies and defines scripts, while composer.lock pins the exact versions that were resolved. When you clone a project, a single composer install reads the lock file and downloads everything into a vendor folder — the first command you'll run on almost any codebase.

Requiring the right way

Adding packages has a couple of flavours worth understanding. composer require <vendor/pkg> adds a normal dependency your app needs to run and updates both composer.json and composer.lock. composer require --dev <pkg> marks it as a dev dependency — tools like PHPUnit and static analysers that you need while building but not in production. On a server you then run composer install --no-dev so those dev tools stay out of your deployment, keeping it lean.

Autoloading and scripts

Composer generates a PSR-4 autoloader so you never write manual require statements. After adding classes outside of a package install you run composer dump-autoload to regenerate it, and composer dump-autoload -o builds an optimized class map that's recommended for production. The scripts section of composer.json defines project tasks run with composer run-script <name>, and composer exec runs a binary shipped by a package from vendor/bin without typing the full path.

Keeping things healthy

A few maintenance habits prevent trouble. composer outdated shows what has newer versions, composer update moves them forward within the ranges your composer.json allows, and composer why <pkg> explains which dependency pulled something in. composer validate checks your manifest before you commit, and composer diagnose hunts for common environment problems. These pair naturally with the Git commands for version control and the Docker commands when you containerise your app.

FAQ

What's the difference between composer install and composer update?
composer install reads composer.lock and installs the exact versions pinned there, so everyone gets identical dependencies; composer update resolves the latest versions allowed by composer.json, installs them, and rewrites composer.lock.
What does composer dump-autoload do?
It regenerates Composer's autoloader files so newly added classes are found. Add -o (--optimize) to build a class map for faster autoloading, which is recommended for production.

More cheatsheets