logo
podcast Podcast
get help Get Unstuck

How do I know if this package is good?

The first three questions I ask

Joel Clermont
Joel Clermont
2025-01-06

Laravel seems to have a package for everything. It's one of the strengths of the Laravel (and broader PHP) ecosystem.

We have so many choices! In fact, there might be even be multiple packages that provide the functionality we're looking for. So how do you know which one you should pick?

Today, I'll share a few basic "sniff tests" I use when evaluating a new package.

The very first question I ask myself is "Do I really even need a package for this?" Once I stop and pause, sometimes I realize the answer is "no".

How much code is it providing? Is this package for one class? Could I just add a class to my app instead? Do I need all the configuration options it provides, or is my use case much simpler?

Bringing in any sort of package, even a well-supported one, adds some additional future friction when it comes time to upgrade. I like to weigh the time to build something myself versus the cost of future maintenance dealing with an upstream package and its own cadence of releases and bugs.

So if it's something relatively simple, a single class, or even a single function, I would likely just write it myself.

Let's assume the scope is big enough that it makes sense to pull in a new dependency. What do I look at next?

This might seem weird, but I will check the tests folder before I even read the docs. I want to know this package is well-tested before I pull it in.

It could have the best features, slickest docs, and shiniest logo out there, but without tests, I simply will not use it. This is non-negotiable for me.

The next thing I look at is how well-supported the package is. How long did it take to support the most recent major version of Laravel? Are there a lot of unanswered issues or unmerged pull requests? Do I see regular commits and releases?

This has to be balanced with the scope and history of the package. Some tools are essentially feature complete and don't have a lot of additional work to be done. So I won't needlessly penalize a package without recent commits if it's reached that point of maturity.

But if it's six months after the last major Laravel version and this package still doesn't support it, I will be more hesitant to pull it into my project. Even worse if there's a PR sitting there adding in support, and it's just been ignored, that would be a red flag to me as well.

Once those first few hurdles are cleared, then I'll dig deeper into the docs and make a more nuanced decision as to how well this package aligns with my needs.

Here to help,

Joel

P.S. Another great way to learn about packages is asking other devs who have used them. Why not ask in the Mastering Laravel community?

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼
email
No spam. Only real-world advice you can use.