Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Eternal Dilemma of Dealing with Dependencies

DZone's Guide to

The Eternal Dilemma of Dealing with Dependencies

Handling dependencies is one of important challenges in any software project—and especially in the fast-moving JavaScript world, we need to experiment to find the optimal workflow.

· Web Dev Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

The Dependency Dilemma

Our Nettbutikk team just had a heated discussion about handling upgrades of our dependencies that contines our learning journey lined with failures (or rather “experiments that generated new knowledge”).

Failed Attempt One: Let Tools Do It

Originally we let npm automatically do minor upgrades but that turned out to be problematic as even minor version changes can introduce bugs and having potentially different (minor) versions on our different machines and in production makes troubleshooting difficult.

Also, this only takes care about minor version changes. When we decided to do the bigger updates, we had a lot of work and testing to do, making sure all the new versions work together. Troubleshooting of upgrade problems was difficult since many libraries were changed at once so pinpointing the source of a new defect was nontrivial.

Failed Attempt Two: Let a Human Try

Next we decided to freeze the library versions completely and let the one of us that had the operations role that week run npm outdated, update all dependencies, and verify everything still worked.

Thus we ensured that we were almost always up-to-date and that we typically had only a small job to do, with just a small potential for problems. However it wasn’t frictionless either. It might require one or few hours (for proper testing and occasional troubleshooting) every week, a time we would have rather used on creating new value. And sometimes the upgrade did introduce problems – some spot and fixed immediately, but some taking more time to discover and fix. Once it took two weeks to find out that something broke due to a Reflux upgrade – and finding out that the cause was the upgrade wasn’t easy.

New Experiment: Upgrade As Needed and Mitigate

Our reliable though-challenger Alex pointed out that upgrades give us typically little value at a relatively high cost. So we have decided to try not upgrading libraries unless we would have a good reason to do it (such as a known security problem or a new functionality we want). It is obviously not optimal and the upgrades might be big and painful but we will try it for a while and evaluate how it works for us.

Conclusion

Handling and upgrading dependencies is difficult and costly. It’s important to evaluate the cost-benefit ration and experiment to find the “least bad” approach and balance for a particular team. Development is fun.

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:
devops ,javascript

Published at DZone with permission of Jakub Holý, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}