What do you do when you rely on packages, and bugs arise?


#1

I feel like 3rd party packages can be a double-edged sword. On one hand, they cut out a lot of development time with instant out-of-the-box functionality. But the down side is when bugs pop up, or they add a new feature that doesn’t entirely work, and your client is really pushing for something to get done that relies on said package.

What do you do? Do you remove the package and re-build whatever it was doing from scratch? Or dive in, clone the package, and try to fix it yourself, contributing a fix? Seems like the latter is the way to go since it helps the community, except all the time needed to become familiar with the package’s code (which can take longer if it’s not neatly documented—or documented at all).

I’m in such a conundrum right now. I’m under a deadline and it’s a tough spot to be in for sure!


#2

Been there, still there, never gonna leave there. Heck, even today I made a PR to a package, noticed even more errors, said screw it & made my own…(with blackjack & hookers).
Before I got into webdev I was a business analyst, so I take the same approach here. List your business requirements, prioritize them, find the gaps, estimate how much time it’ll take to fill the gaps via bespoke or making PRs (+/- 80% error is AOK). Then, estimate your risk. How much work will it take to debug a new package? How confident are you that you can get rid of all the edge-case bugs? How often do the underlying dependencies change? Then the perks: how much will you learn? will you use it again? what’s the performance boost? (don’t count this unless we’re talking 100ms+).

After all that, I probably end up opting to write my own more often than not. I learn a ton in the process & writing solid code from scratch is easier than debugging ugly code.


#3

What do you do when you rely on packages, and bugs arise?

Cry… maybe weep a little.


#4
  1. Look into the issue and see if I can fix it myself or work around it.
  2. Report the issue with the info that I have gathered in step 1 and ask for help.
  3. If step 1 and step 2 fail, find an alternative.

That said, in the package selection process I already look how good the support is, how many open issues exist and I also skim read through the source code most of the time.