Today we ran into a problem where an abandoned dependency was blocking our ability to update React.
The dependency was added nearly a year ago as our company quickly built and released features.
It fits a specific scenario perfectly, and I can definitely see how the developers working on it at the time saved a lot of time in the short-run to release according to spec.
However, the package has been long abandoned. In fact it hasn't been updated for 3 years. It was never an official package to begin with. While it was a shortcut a long time ago, now it has saddled us with technical debt that can only be addressed either through a significant rewrite or abandoning the feature in its current form.
What's worse is that this package is only used in one place. The code implementing this is also non-trivial meaning that we built a relatively complex bit of code on top of this now defunct third-party library.
Self-reflection
While I didn't implement the code, I realised that this was a mistake that I could just have easily made.
When I was early on in my programming journey I used to love adding packages. It's best not to create something if it is already created right?
I've learned since then that this is not necessarily the case. There are good reasons and bad reasons to use packages.
Packages that aren't updated die. And especially with UI based packages, they don't die a graceful death. Especially in the JavaScript ecosystem changes move so fast that being strategic is important.
A couple of lessons:
Avoid using packages for shortcuts. Yes, they may help now but will you come back and undo the shortcut?
All packages are not created equal. If you have to use packages pick well-maintained ones, unless the package does not need to be updated. For example the package that caused us problems was clearly abandoned before we decided to use it.
Especially avoid packages that themselves have a lot of dependencies that may conflict with your own eg. React.
Ask and ask your self again, do you really need that package? Eg. If the design you are seeking is so complex you need a package yet don't have the time to actually build it yourself, isn't it just better to build something simpler?
Maintaining dependencies take time and effort. Tech debt maintainence is important especially if you decide to rely on a package that is not well maintained.
That being said, the answer is not always to avoid dependencies. The key is to wary and make the decision with both eyes wide open.
Top comments (0)