Introduction

One of the amazing things about Laravel and PHP is the vast ecosystem of community packages available to accelerate your development process. Often, a good package helps you implement complex features in your web application more quickly than writing the code yourself from scratch. I love the feeling of finding a package that does exactly what I need — it keeps the job enjoyable and makes me appreciate the efforts of the open-source community. I also maintain a few open-source packages myself, such as Laravel Exchange Rates, Short URL, Laravel Config Validator, and Favicon Fetcher.

However, we should be mindful of the potential tradeoffs of reaching for packages too quickly, since each package added to your project is an external dependency out of your control.

In this article, I'm going to cover eight questions that go through my mind when deciding whether or not to use a package.

1. Could You Write the Code Yourself?

Before using a package, consider if you can write the code yourself. If the required code is too complex or time-consuming to write and maintain yourself, reaching for a package is a great option. However, you need to evaluate the code complexity with the tradeoff and the maintenance overhead of using a package maintained by someone external to your team.

For example, imagine you need to make requests to the Digital Ocean API. It makes much more sense to use Digital Ocean's PHP package, with tested support for complex features like authentication and making the correct HTTP requests. Attempting to write this code yourself doesn’t make sense.

However, for a simple feature like checking whether a number is odd, it’s better to write this on our own, avoiding an external dependency. It’s hard to believe that this JavaScript library gets 250k+ downloads a month!

2. Is the Package Going to Restrict You?

One of the great things about working with packages is that it can feel like you're building your app like a jigsaw puzzle — piecing together multiple small packages to make a large application. However, since packages are generally designed to be generic and decoupled from the rest of your codebase, they don’t always fit your intended workflow.

For example, take my Short URL package: a Laravel package that allows you to create shortened URLs within your Laravel application. My main goal when building this package was to make it as simple as possible to install and use in your project. Ideally, it should only take a few minutes to install, configure, and start using.

I know for certain that the package works really well for creating short URLs and storing them in the database. However, it's not well suited for something like bulk-creating short URLs, since it inserts short URLs in the database one by one (i.e., creating 1,000 short URLs at once, requires 1,000 database inserts). Obviously, this isn’t very efficient, but I’m comfortable with this limitation.

In my opinion, if you're building an application that actually requires the bulk insertion of 1,000 short URLs at once, you should use a package built for that specific use case. If you can’t find a suitable package, implement that feature yourself — and consider releasing a new package as well.

The key takeaway here is to always ask yourself if the package neatly fits into your intended workflow or if you'll need some hacks to get it working. If you're not sure, try installing the package on a test git branch and experimenting with it to see if it fits your needs. If the package isn’t a good fit, you can always roll back and explore other ideas.

At the same time, if you notice potential issues and/or bugs in the package and have some solutions, consider submitting a pull request to improve the package. Contributing to open-source projects can be extremely rewarding, and helps other developers experiencing the same issues.

3. Is the Package Still Maintained?

When you're looking at a package, it's important to check whether it's still maintained.

If a package is outdated or no longer maintained, it’s risky to use in your project. For example, let's say you used a package for an important feature while on PHP 8.2, but now you want to update your project to PHP 8.3. If the package lacks PHP 8.3 support, and is no longer maintained by the owner, you're forced to make one of the following difficult decisions:

• Ask (or hope) the package maintainer adds support for PHP 8.3.
• Make a pull request to add support for PHP 8.3 and hope they merge it in.
• Re-implement the feature in your application using a different package.
• Rewrite the code yourself.
• Fork the package and start maintaining your own version of it.
• Continue using PHP 8.2.

Let's be honest, none of these really sound ideal. We want to want to keep building cool new features in our app, not worry about maintaining existing features.

So how do you know if a package is still being maintained? Here are a few checks:

• Check for stale issues in the repository — issues that haven't been answered or closed.
• Check if there are old, but active, pull requests.
• Check how long since the last commit was made to the codebase.

Note: It's very important to remember that the lack of recent commits isn't always bad. It might mean that the package is mature or feature-complete and only requires security updates going forward (e.g. PHP/ Laravel updates). Evaluate each package individually when deciding whether or not to use it.

4. Does the Package Have Tests?

Another important factor to consider when deciding whether to use a package is if it has any tests.

When you install a package, it becomes part of your codebase. Since you wouldn't write any code yourself without writing tests (right!? 😉), it's important to make sure the package has a quality test suite. A good test suite minimises the risk of a package introducing new bugs that could break your application.

Note: The lack of tests doesn't always mean there are bugs. In fact, if the package is relatively new, the maintainer might still be working on the tests. Personally, when I'm building a new package, I add the tests closer to the release, because the code is changing so often. I learned the importance of writing tests after building my first package.

5. Does the Package Have Good Documentation?

Good documentation is a seriously underrated, but very important, part of a package.

There's nothing worse than getting stuck on a problem and not being able to find any documentation online. I've been forced to work with some APIs and packages with outdated (or non-existent) documentation, and it wasn’t fun. It slows you down, forcing you to spend more time diving into a package's code rather than building new features.

Good documentation helps you understand how the package works.

6. Is the Code Quality Good?

It's sometimes worth diving into the package's code and checking out the general quality.

As I mentioned before, when you install a package, it becomes part of your project's codebase. Would you accept a pull request from a team member if the code was poor quality, had bugs, or had potential security vulnerabilities? You need to think the same way when considering a third-party package.

The code doesn't need to be perfect, but you want to avoid introducing any obvious bugs or security vulnerabilities into your system by including it.

7. Is the Package Popular or Reputable?

Generally speaking, popular packages from reputable developers are more likely to be supported and maintained in the future, making them less risky to use.

These metrics, taken together, should give you an idea of a package’s popularity:

• Total (or monthly) downloads
• Number of contributors
• Number of projects using it
• The developers maintaining the package
• Number of forks on GitHub
• Number of stars on GitHub
• Number of watchers on GitHub

For example, let's take look at the metrics for Spatie's Laravel Permission package at the time of this writing:

• 25 million total downloads
• 176 contributors
• 54.7k projects using it (according to GitHub)
• 1.7k forks
• 10.9k GitHub stars
• 199 watchers

I don't know about you, but this seems like a very popular package to me. These numbers make me confident that the package isn't just going to fizzle out of existence any time soon compared to a package that has one contributor and no stars.

Note: Remember that everyone has to start somewhere. Maybe you found a package that’s a perfect fit for your project but is maintained by someone just getting started. When I first built Laravel Exchange Rates, it took time to start getting significant downloads — and I totally understand. Interest finally surged when the package was shared by Laravel News. So if you come across a high-quality, but less popular package, it doesn't always mean it's bad; you might just be early.

8. Are You Happy with the Maintainer Having the Final Say?

Finally, remember that third-party packages are created and maintained by other developers or companies — giving them the final say on new features, breaking changes, and project roadmaps. When deciding to use a package, consider the potential impact on your application if they stop maintaining the package or release a large breaking change. Depending on your project, it could be minimal or a deal breaker. Regardless, be sure to spend some time considering this scenario.

Conclusion

Being part of a vibrant developer community, with so many high-quality packages, is like being a kid in a candy store. But it’s important to take your time and think through your package choices, weighing all the costs and benefits. Hopefully, these eight questions help you make the right choice for your project.

If you enjoyed reading this post, I'd love to hear about it. Likewise, if you have any feedback to improve the future ones, I'd also love to hear that too.

You might also be interested in checking out my 220+ page ebook "Battle Ready Laravel" which covers similar topics in more depth.

If you're interested in getting updated when I publish a new post, sign up for my newsletter.

Keep on building awesome stuff! 🚀