Updating Packages

Libraries release fixes and new versions all the time. Composer gives you control over when and how you update.

See what is outdated

1

composer outdated

This lists your direct dependencies that have newer versions. Without any outdated packages, Composer prints nothing, or tells you everything is up to date.

Update everything allowed by composer.json

1

composer update

Composer looks for the newest versions that still satisfy your constraints in composer.json, installs them, and rewrites composer.lock.

Update one package

1

composer update monolog/monolog

Safer: only that package (and what it needs) changes. Use it when you want a specific fix without touching the rest.

update vs install

On a live server, run composer install, never composer update. You want the versions you tested, not whatever is newest today.

Major updates

Constraints such as ^2.0 stop at the next major version (3.0). To move to a new major version, change the constraint yourself and read the package’s upgrade notes, because major versions may break things.

1

composer require league/commonmark:^3.0

A safe update routine

1. Commit your work.
2. Run composer outdated and read the changes that matter.
3. Run composer update (or update one package).
4. Run your tests, and click through the app.
5. Commit both composer.json and composer.lock.

Security advisories

1

composer audit

Composer checks the installed versions against a list of known security problems and tells you which packages to update. Run it regularly and in your automated build.

When an update fails

Composer may report a conflict: package A needs B version 1, package C needs B version 2. Read the message. The usual solutions are to update the packages together, loosen a constraint, or pick a different package.

1
2

composer why-not vendor/package 2.0   # explains what blocks a version
composer why vendor/package           # explains who needs a package

Dry run

1

composer update --dry-run

Shows what would change without changing anything.