- 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.
- 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.
: 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.