Introduction

A composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you.

The composer is not a package manager in the same sense as Yum or Apt. Yes, deals with "packages" or libraries, but it manages them on a per-project basis. I am not going to explain the basics like how to install & set up it. In this article, I am going to explain the importance of keeping your dependencies up-to-date.

Why should I keep my dependencies up-to-date?

Not updating your dependencies has its benefits - you are guaranteed that the interface of the dependency will not change for example. It has some downsides as well, however; You will miss out on security updates, new features, and improvements.

Another reason to keep your dependencies up-to-date is to keep your migrations small. It is - usually - simpler to migrate a minor version than to migrate a major version1 as minor upgrades usually contain fewer changes and should not introduce breaking changes.

Finding Outdated Packages

The simplest way to find out if you have dependencies that are not up-to-date is to run composer outdated.

composer outdated

This command will output a list of all dependencies - both direct dependencies and indirect dependencies & their current version in your composer.lock and their most recent version.

Dependencies that are up-to-date are by default not shown. If you do want to show these add the flag -a or --all . There are some more useful flags please check with the composer outdated.

composer outdated --all

New Composer Bump Command

This command increases the requirements listed in the composer.json file with the currently installed version numbers. When the version numbers are bumped in the composer.json file, it effectively prevents Composer from installing a lower version of the required packages.

composer bump

Some of the available flags are

• --dev-only: Only bump requirements in "require-dev".

• --no-dev-only: Only bump requirements in "require".

• --dry-run: Outputs the packages to bump, but will not execute anything.

Running this blindly on libraries is NOT recommended as it will narrow down your allowed dependencies, which may cause dependency hell for your users.

{
   "require": {
        "phpunit/phpunit": "^9.4" // old version 
        "phpunit/phpunit": "^9.5.20" //Latest version
   }
}

The composer Bump command does not update platform requirements such as the PHP version or extension versions.

Note :
The composer bump command requires a composer.lock file that is up to date. This is because the composer bump inspects the composer.lock file to determine the currently installed versions.

Updating Specific packages

So what if one or more dependencies are outdated? You update them! To update dependencies two commands can be used: composer update & composer require.

The difference between these two commands is that composer update will try to update a dependency based on the current constraints at composer.json a file and will only update composer.lock. With composer require however Composer will try to install the latest version - keeping existing dependencies and platform constraints in mind - and will update both composer.json and composer.lock. This difference also means that composer updates typically will not update a package to a new major version.

composer update

When you're working on a large codebase with a lot of dependencies, updating all of them might result in a lot of new packages. This can be undesirable as you might not know how and where all these dependencies are used. If that is the case you can limit the dependencies to be updated by specifying them.

composer update psr/container psr/log

The side effect of specifying what dependencies should be updated is that Composer will not update any other packages.

To update the package to a specific version we can use this command below by specifying the version at the end.

composer update saravanasai/packagename:1.1.0

Your constraint should reflect the versions that your codebase supports.

Debugging updates

Composer offers two commands that are instrumental when maintaining larger codebases composer why and composer why-not.

The main use case for composer why is to find out why an indirect dependency is present in your composer.lock

composer why paragonie/random_compat

//terminal - output
ramsey/uuid 3.9.3 requires paragonie/random_compat (^1|^2 |9.99)

composer why-not can tell you the exact opposite. I have found this to be very useful when I find myself in a situation where I'm unable to update an indirect dependency to a specific version

composer why-not paragonie/random_compat:9.99.100
//terminal - output
ramsey/uuid 3.9.3 requires paragonie/random_compat (^1 | ^2 |9.99)

It also works for requirements like the PHP version. This realization was a very big help in preparing our codebases for the migration to PHP 8.

Conclusion

Please share & like Feel free to share your inputs in the comments for improvements.