Top 3 Reasons Why FREE Dependencies are Not Exactly FREE

I’ve seen this happen so many times, especially with devs who are newer to PHP, or come from JS. Their composer.json looks is an endles...

I’ve seen this happen so many times, especially with devs who are newer to PHP, or come from JS. Their composer.json looks is an endless list of third-party packages. Yes. You can quickly get something done by patching together this package and that package. But that doesn't mean you should.

In this article I'm going to argue that in production apps… and in general in long-term apps… you should avoid new dependencies like the plague.

Why am I saying that? Because there are hidden costs to using a Composer package. Even if that package is FREE and open-source. Here's my top 3 reasons:

1. Every extra dependency might slow down your upgrade path

Example: you’re ready to upgrade your whole project to PHP 8.3 but… you can’t. Because one of those 20 dependencies of yours… hasn’t supported it yet. And doesn’t answer on Github. So what do you do? You either delay your upgrade... or do work-arounds to support their package. Maybe even submit a PR to their repo, and use your branch until they do. While this is good for the open-source community... is it good for your project. For your client? I would argue no. I would argue this only makes sense for packages that are crucial for the project.

My rule of thumb: Only use packages that look well-maintained. Look at "Releases" on Github and see how often they're made. Look at their Issues and PRs and see how many there are, how responsive the maintainers are. Corroborate that with the size of the package - for a big package it's normal to have a lot of issues. For a small one... it's a red flag.

2. Every extra package is a potential security vulnerability

I’ve maintained packages for long enough to see PRs specially crafted to introduce vulnerabilities. Yes, that's a thing. Not only accidental security vulnerabilities, but also intentional. The more vendors you use… the higher the likelihood one has passed through.

My rule of thumb: Try to use as few package vendors as possible. Preferably only vendors you trust. Have you already used packages from Spatie or Backpack or whatever other vendor? Prefer those.

3. Every extra package can add breaking changes

Every developer has the right to push his package forward. To push new versions, with breaking changes. But when they do… you have to follow their upgrade guide, and go in that direction, even if you don't actually need any of the new features. That takes time. Your time.

My rule of thumb: Pay special attention to single-purpose packages, you could live without them:

• if it takes more time to learn and use the package, than to implement the functionality… do it yourself;
• if you only need one small functionality and the package provides 100… do it yourself;

For example:

• I needed to implement "Impersonate" functionality, for the admin to act as a specific user. A dev suggested I use this package. Hell no! Took me 30 min to implement it myself. Zero added dependencies!
• I needed to make a call to PipeDrive to add a deal. One of my devs recommended we use a 3rd party PHP library for it. Hell no! I’d much rather make a simple HTTP call. Zero added dependencies!

--

Am I saying that you should never install packages for third parties? No! The web is built on open-source. But for your long-term peace of mind, I'd recommend you develop the habit of only adding dependencies only when absolutely needed.

Maybe that’s just me. But it’s helped me in the past. And wanted to write out my opinion on this, for reference, for posterity and for others to pitch in with theirs.

Do you agree or disagree? Let me know in the comments below 👇

Cheers!