Packages bring a lot of value: they're reusable components, ready to be downloaded and just work! Magic, right? Needles to say, when I discovered them, I felt like a kid in a candy store. The more the better! Right? right?
For experimenting: yes! Of production-ready things: not so much...
The hidden cost
Packages bring a hidden, but often use cost with them. Your project becomes dependent on code from someone else. What if you need an update for the new PHP version a year down the line? What if you discover a security risk that needs urgent fixing? These are serious downsides to consider that might not come up immediately.
Being dependent on a stale external package can tank your development speed and even whole project!
On the other hand, avoiding packages all together means you'll miss out on a lot of useful stuff! If your production is shipping to production at some point, you'll want to get the perks and limit the risk of downsides by focussing on high quality, living packages.
A checklist to minimise the risk
I have a mental checklist to decide on a package and hope to help others by sharing it. Here we go:
⭐️ Github stars
The more stars, the more users. Read: a higher amount of people potentially contributing to the project, or taking over when the maintainer lacks time.
🕙 Time of the last update in the code
This could tell you a lot about the current state of the project. Is it actively updated? Only bug fixes? Or abandoned (not always mentioned in the readme)?
✏️ Documentation
The presence and quality of the documentation will have a huge impact on your development speed.
🚩 Issues & pull requests
Are these actively maintained? Do they show known bugs? Is the author open to pull requests for features you want but might not be there yet?
Lastly: A lot of open source maintainers do this entirely voluntary. This comes with a very different set of expectations than when you make use of a paid service. Be kind! And should you wish to do so, they're often happy to receive help on the project. It's a very rare industry where so many people share for free, let's celebrate that!
Happy packaging!
Top comments (2)
There's a few things to take in to consideration when determining if you should use a library or roll your own. You've mentioned some great items to consider. Developers should also consider whether they will have the bandwidth to create and maintain an in-house library. If they do, great, just make sure to document the library for the next dev.
Absolutely! Creating in-house is a whole other challenge, but definitely an interesting one and one that can pay off a lot over the years.