/commands/composer/composer-update-single-package
composer update vendor/package: update one package without touching the others
- tool
- Composer
- versions
- Composer 2.x
- os
- any
composer update monolog/monolog updates only that package to the newest version allowed by its constraint in composer.json, and writes the new version to composer.lock. Every other package stays at its locked version. Add -w to let the package's own dependencies move too, or -W to also move dependencies that are root requirements, when the new version needs them. composer outdated shows what is behind first.
Usage
composer outdated --direct # direct dependencies with newer versions
composer update monolog/monolog # one package, within its constraint
composer update monolog/monolog -w # plus its dependencies
composer update monolog/monolog -W # plus dependencies that are also root requirements
composer update "symfony/*" # every package matching a pattern
composer update monolog/monolog --dry-run # show what would change
composer update --lock # only refresh the lock file hashRun composer outdated (or composer outdated vendor/package) to see installed and latest versions; packages whose latest version is outside the constraint are marked, so you can tell which updates need a change in composer.json.
Options
| Option | What it does |
|---|---|
| vendor/package | Limit the update to this package (several names or wildcards allowed) |
| -w, --with-dependencies | Also update its dependencies, except root requirements |
| -W, --with-all-dependencies | Also update its dependencies, root requirements included |
| --with vendor/pkg:2.1.0 | Temporarily constrain a package for this update |
| --dry-run | Print the operations without changing anything |
| --prefer-lowest | Pick the lowest allowed versions (for testing libraries) |
| --no-dev | Skip require-dev packages |
| --lock | Only update the lock file hash, no package versions |
| --minimal-changes (-m) | With -w/-W, change only the dependencies that really have to move |
Pitfalls
composer updatewith no name updates everything within the constraints. That is a large change for a production project; name the packages you mean.- Major versions need a new constraint. If
composer.jsonsays^2.0,composer updatenever installs 3.x. Change the constraint withcomposer require vendor/package:^3.0, see composer require a specific version. - Lock file out of date. After editing
composer.jsonby hand,composer installwarns that the lock file is not up to date. Runcomposer update vendor/packagefor the changed package, orcomposer update --lock. - Conflicts. When the new version needs different dependency versions, Composer reports Your requirements could not be resolved; try again with
-W. - Production deploys should run
composer installfrom the committed lock file, nevercomposer update; see composer install vs composer update.
How to confirm it worked
The command lists each operation (Upgrading monolog/monolog (3.6.0 => 3.7.0)) before writing the lock file. Afterwards composer show monolog/monolog prints the installed version and git diff composer.lock shows that only the expected packages changed.
FAQ
Why did composer update vendor/package not update it?
Either the newest version is outside the constraint in composer.json, or a dependency of the package is locked at a version the new release does not accept. Check with composer why-not vendor/package VERSION, then widen the constraint or add -W.
What is the difference between -w and -W?
-w (--with-dependencies) also updates the package's own dependencies unless they are root requirements. -W (--with-all-dependencies) updates them even when they are also required directly in composer.json.
How do I refresh composer.lock after editing composer.json without upgrading anything?
Run composer update --lock. It updates the lock file hash and metadata so the lock file is no longer out of date, without changing package versions.