Adding library as dependency only to use one function

Question

Few months ago I started working in a team that develops software using Node.js. Quite often we encounter the problem that has been already solved by someone else and the solution is already available in npm registry. Some examples of these problems include: writing deep merge function, writing single value to JSON file and others. And almost always during code review phase the discussion follows, with some developers saying that it is not worth to add the whole library just to fix this problem, while others disagree.

In result, we usually agree to just use a library approach (instead of copying plain javascript code from StackOverflow). However some members of the team are not happy with that, as only after few weeks of work, our very basic React+Express CRUD app already have over 15 dependencies in our package.json.

These are the pros of each approach that I can think of:

Using npm package to solve your problem

• time-efficient

• probably more reliable since many people are using it (not always true)

• in most cases cleaner, smaller project codebase

Writing plain JavaScript code/Copying code from StackOverflow

• Less dependencies to manage

• Less dead code (99% of code in the library is not used by us)

• Less knowledge needed to understand the code (every developer knows JavaScript, not everyone knows how exactly library X works)

• Less maintenance needed in the long term (some teams in our company need to accomodate time in pretty much every sprint to deal with outdated/problematic dependencies in bigger projects with 50+ npm packages in package.json)

Which approach is better?

Answer 1

This really really depends and has to be decided on a case by case basis. Also, the modern JavaScript ecosystem has a strong bias towards using tiny libraries, so conventions from other ecosystems do not carry over as well.

In general:

• Maintaining simple utility functions yourself is less hassle than tracking external dependencies.
• Some huge frameworks can be avoided by a few 100s lines of simple code.^[1]
• Do not reinvent complicated libraries, especially if they are security-sensitive or outside of your area of expertise.
• Being part of a widely accepted, stable ecosystem is good. Living on the bleeding edge takes more effort.

^{[1]: especially if writing and testing the code is faster than reading the docs, or worse, having to read the source code in absence of usable docs.}

For example, it wouldn't be a good idea to reinvent crypto libraries or React, but there's no good reason to depend on external packages for trivial utilities like left-pad. Functionality like test frameworks or web frameworks can be surprisingly easy to write yourself. But since there are already wide-spread, stable packages for this (often with their own ecosystem of extensions) and this functionality is outside of your area of expertise, you would be wasting your time to rewrite them.

The decision to use versus rewrite existing code also has far-reaching implications for your business – especially which kinds of liabilities and risks the business is willing to take on.

• Consider supply chain security. When using external packages, will you audit them before updating? Consider also transitive dependencies.
• Consider security updates. What is your plan for managing dependency updates in a timely manner? What happens when the upstream project is no longer maintained? For code that you write yourself, how will you ensure it is reasonably free of vulnerabilities?
• Consider license compliance, including compliance for transitive dependencies. I have a hunch that huge parts of the NPM ecosystem might be accidentally violating their licenses. Writing code yourself avoids this problem. Note that code on Stack Overflow is usually licensed under terms that are unsuitable for copying into other projects (the CC-BY-SA 3.0 is a copyleft license, similar to the GPL).

When you have found a library that you want to use, you have a variety of options how to do that. These different options give you different amounts of control, but also imply different amounts of effort when considering updates:

• using the public NPM registry to manage the dependency: low update hassle, but little control.
• forking the package in compliance with its license: medium update hassle but decent control.
• copying the library in whole or in part into your project, in compliance with its license: significant initial work to isolate relevant parts, and no reasonable way to manage updates. However, this gives you a lot of control over the code, incl. the possibility to tweak it to your needs.
• writing your own version: except for trivial utilities, this won't be worth your time. However, this provides ultimate control.

Control doesn't just mean being able to plan updates, but also the possibility of fixing critical bugs yourself. Especially smaller open source packages might not have the resources to address issues quickly. Quite possibly, writing code yourself has the same maintenance effort as using a niche dependency.

Answer 2

Regardless of other concerns, using a javascript library will only save you time (and ergo money) if you don't check the code, and every subsequent update, for security risks.

So you are really asking yourself if you can trust the publisher of that particular library.

In my view this arguement really cuts out 99.999% of all libraries and the minor developer centric arguements fall away.