Avoid some common Composer dependency issues

Today I wanted to share a tool I learned about in the same talk on zombie code I mentioned yesterday.

It's useful for auditing your project for a few common problems with Composer dependencies.

One basic thing it can help identify is an unused dependency. If there is something installed in my composer.json, but that isn't being used anywhere in my application code, we should get rid of it. Over the life of a project, it can be easy to lose track of things you've stopped using. One word of warning, it can incorrectly identify a package as unused. For example, it said I wasn't using the league/flysystem-aws-s3-v3 package, but only because I was using it via the Storage helpers in Laravel. But even still, it's a useful way to audit your packages.

Another useful detection it offers is for "shadow dependencies". These are packages that your application code uses but aren't explicitly declared in your composer.json file. For example, Laravel has a dependency on the league/commonmark package for using Markdown in mailables. But if my application reaches into that package and starts importing classes, I now have a "shadow" dependency. What happens if a future version of Laravel switches to a different package for Markdown? My code will break.

Another useful thing it can find is a misplaced dependency, either something in dev dependencies that is actually used in application code, or vice versa.

The tool is called Composer Dependency Analyser and it is extremely lightweight, having no dependencies itself, so you can easily bring it in and use it to audit your project's dependencies.

Here to help,

Joel

P.S. Would you like an experienced Laravel developer to review your code and make practical suggestions? Book a free call and let's talk.