/flags/composer/composer-update-with-all-dependencies
composer update -W (--with-all-dependencies): update a package and its dependencies
- tool
- Composer
- command
- composer update, composer require
- flag
- -W, --with-all-dependencies; -w, --with-dependencies
- default
- off (only the named packages are updated; everything else stays locked)
composer update vendor/package is a partial update: Composer updates only the named package and keeps every other entry in composer.lock fixed. When the newer version needs newer dependencies, that restriction makes the update fail with "Your requirements could not be resolved to an installable set of packages" or leaves the package where it was. composer update vendor/package -W (long form --with-all-dependencies) allows Composer to update the package's dependencies too, including those you require directly in composer.json. -w is the narrower form that leaves root requirements alone.
Commands
composer update symfony/console # only symfony/console
composer update symfony/console -w # plus its dependencies that are not root requirements
composer update symfony/console -W # plus all of its dependencies, root ones included
composer require guzzlehttp/guzzle:^7.9 -W # change a constraint and update what it needs
composer update "symfony/*" -W # wildcards work tooUse --dry-run first to see which packages would move before writing the lock file.
Options compared
| Option | Updates |
|---|---|
| (none) | Only the packages named on the command line |
| -w, --with-dependencies | Also their dependencies, except packages listed in your require/require-dev |
| -W, --with-all-dependencies | Also their dependencies, including root requirements |
| --with vendor/pkg:2.0.1 | Temporary extra constraint for this update |
| -m, --minimal-changes | Change only what is absolutely necessary |
| COMPOSER_WITH_ALL_DEPENDENCIES=1 | Environment variable form of -W |
Root requirements still keep their constraints from composer.json: -W can move psr/log from 2.0 to 3.0 only if your own constraint allows 3.0. If it does not, change the constraint with composer require.
Reading a failed partial update
When the partial update fails, the solver output usually contains a line saying that the locked version of some dependency conflicts and that --with-all-dependencies (-W) can be used to allow updating it. That hint is exactly the case this option exists for. To see which package blocks a version, ask composer why-not:
composer why-not symfony/console 7.2Pitfalls
-Wcan update more packages than you expect, including major versions of root requirements whose constraints allow it. Reviewcomposer.lockchanges in the pull request.- Run tests after the update; a dependency update can break code even when Composer is satisfied.
- Never run
composer updateon a production server; update locally or in CI and deploy the lock file withcomposer install. - Updating a single package step by step is covered in composer update one package, and the general resolution error in Your requirements could not be resolved.
FAQ
What is the difference between -w and -W?
-w (--with-dependencies) also updates the dependencies of the named packages, except those that are themselves root requirements in composer.json. -W (--with-all-dependencies) updates those root requirements too, within their constraints.
Why does composer update vendor/package not update anything?
A partial update keeps every other locked package fixed. If the new version needs a newer dependency, the solver cannot find a solution and keeps the old version or fails. Add -W to let it move the dependencies as well.
Does -W work with composer require?
Yes. composer require vendor/package:^3.0 -W adds or changes the requirement and allows the dependencies, including root ones, to be updated in the same step.