Cookie Consent by Free Privacy Policy Generator ๐Ÿ“Œ 8 Essential Questions to Ask Before Using a Laravel Package

๐Ÿ  Team IT Security News ist eine Online-Plattform, die sich auf die Bereitstellung von Informationen,alle 15 Minuten neuste Nachrichten, Bildungsressourcen und Dienstleistungen rund um das Thema IT-Sicherheit spezialisiert hat.
Ob es sich um aktuelle Nachrichten, Fachartikel, Blogbeitrรคge, Webinare, Tutorials, oder Tipps & Tricks handelt, bietet seinen Nutzern einen umfassenden รœberblick รผber die wichtigsten Aspekte der IT-Sicherheit in einer sich stรคndig verรคndernden digitalen Welt.

16.12.2023 - TIP: Wer den Cookie Consent Banner akzeptiert, kann z.B. von Englisch nach Deutsch รผbersetzen, erst Englisch auswรคhlen dann wieder Deutsch!

Google Android Playstore Download Button fรผr Team IT Security

๐Ÿ“š 8 Essential Questions to Ask Before Using a Laravel Package

๐Ÿ’ก Newskategorie: Programmierung
๐Ÿ”— Quelle:


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.


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! ๐Ÿš€


๐Ÿ“Œ 8 Essential Questions to Ask Before Using a Laravel Package

๐Ÿ“ˆ 71.98 Punkte

๐Ÿ“Œ Buying encryption? Five good questions to ask before you do

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ Osterman Researchโ€™s Key Questions to Ask Before Implementing EDR

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ Questions to Ask Before Choosing a Threat Intelligence RFI Service

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ 6 questions to ask before encrypting application layer data

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ 6 Questions Attackers Ask Before Choosing an Asset to Exploit

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ Ransomware: Five questions you need to ask about your defences, before you get attacked

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ 8 questions to ask yourself before getting a home security camera

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ Questions To Ask Managed Service Providers (MSPs) Before Hiring One

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ 6 Questions to Ask Yourself Before Outsourcing Vulnerability Management

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ 5 Questions You Should Ask Yourself Before Accepting A Job Offer

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ 4 Questions to Ask Yourself Before Working on a Machine Learning Model

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ 5 Must-Ask questions before you implement Caching

๐Ÿ“ˆ 30.25 Punkte

๐Ÿ“Œ Low CVE-2019-17433: Laravel-admin Laravel-admin

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ Low CVE-2019-17494: Laravel-bjyblog project Laravel-bjyblog

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ I Built Laravel 10 Blog with Admin Panel #laravel

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ Customize Error Views in Laravel #laravel #php #laravelhint #thecodeholic

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ Laravel Boiler Template: Elevate Your Laravel Experience

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ Project setup with Laravel Sail - Part 1 | Laravel Social Media Website

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ I built $7000 Laravel Project #laravel #laravelproject #laraveldeveloper #laravelframework

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ I built $7,000 Laravel Project for YouTube #laravel #laravelproject #laravelframework

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ Deploy Laravel with Github Actions - Part 45 | Laravel Social Media Website

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ Laravel 10 + NGINX + PHP-FPM - my ready to use all in one recipe for your Laravel 10 deployment in Docker

๐Ÿ“ˆ 29.92 Punkte

๐Ÿ“Œ Maximizing Laravel Performance: Essential Optimization Strategies for Web Developers

๐Ÿ“ˆ 26.33 Punkte

๐Ÿ“Œ Voyager Package up to 1.2.7 on Laravel privilege escalation [CVE-2019-17050]

๐Ÿ“ˆ 25.01 Punkte

๐Ÿ“Œ Laravel up to 6.20.10/7.30.1/8.22.0 Iilluminate Database Package injection

๐Ÿ“ˆ 25.01 Punkte

๐Ÿ“Œ Essential Phone: Essential PH-1 bald auch in Europa erhรคltlich

๐Ÿ“ˆ 22.75 Punkte

๐Ÿ“Œ Australian government looks to make Essential Eight essential

๐Ÿ“ˆ 22.75 Punkte

๐Ÿ“Œ #0daytoday #WordPress Essential Blocks 4.2.0 / Essential Blocks Pro 1.1.0 PHP Object Injection Vuln [#0day #Exploit]

๐Ÿ“ˆ 22.75 Punkte

๐Ÿ“Œ Razer Basilisk Essential Review - A Gamer's Essential Tool

๐Ÿ“ˆ 22.75 Punkte

๐Ÿ“Œ 6 Essential Leadership Questions For Equifax

๐Ÿ“ˆ 21.82 Punkte

๐Ÿ“Œ Essential questions for developing effective human rights policies

๐Ÿ“ˆ 21.82 Punkte

๐Ÿ“Œ Questions and Answers - Post your questions now

๐Ÿ“ˆ 20.89 Punkte