Relying Less on NPM

Brian Chen
4 min readDec 29, 2020
Building blocks by @kellysikkema on unsplash

If you’ve read my previous posts, I’m a JS web developer. I live in a sprawling world of open source libraries and dependencies through NPM. But sometimes although there’s a library that does the job well enough, I like to build it myself, and so should you.

Let’s say you want a function that loops through an array of strings and returns you an array with the string from the previous array but they’re now all capital cased. It’s pretty trivial I know but stick with me. What’s your first instinct on implementation?

  • Do you see if it’s common enough for lodash to have implemented since they have plenty of functions that handle arrays?
  • Do you search npm for some keywords like “array string to capital case”
  • Or do you create yourself a function to handle it

The choice is up to you, but 9 times out of 10, I’d build something like this myself. “WHY” I hear people crying out, why would you waste your effort and time to recreate something that probably someone else has already made.

Well it all comes down to a number of factors and generally I come to the conclusion that it’s the simplest approach.

Maintain Project Consistency

My example was very trivial, this time let’s think React. For a React component how do you style it, do you use classnames, inline styles, JSS, or something else? Well if you use a third party component you may need to break that consistency. Personally I like to use css-in-js solutions such as JSS due to their programmatic nature and the reuse of variables through JS, but if the component was built using classnames, I will be forced to break my consistency to make the component work to my liking.

Tight Integration

But let’s say I build that component myself. I now have full control, yes it’s a bit more challenging but you can tweak and tune areas to your liking. I think these words from Rome Tools says really hits the nail on the coffin.

No external dependencies. This allows us to develop faster and provide a more cohesive experience by integrating internal libraries more tightly and sharing concepts and abstractions. There always exist opportunities to have a better experience by having something purpose-built.

Key take away being purpose-built. What you build yourself works exactly as you need it to and if it’s for a frontend, will look exactly as the business requires, down to the smallest detail. A completely zero compromise feature.

Trust me it’s not that Hard

As JS developers we get so many libraries to choose from it becomes a natural habit to look out to NPM for everything, but if you take the time to break down what you really need, often times the functionality you require is not that hard to develop yourself. Often times, these open source libraries are used by thousands to millions of people, although this comes with battle-hardened code resilience, it also leads to many edge cases and use cases, many of which you will never need, and don’t we always want the simplest solution?

The 1 out of 10

You may wonder what the 1 out of 10 times I choose to use an external library may come from. Well quite simply, there are libraries that I simply can’t not recreate myself without considerable effort, to a point where the points above do not outweigh the effort. These usually come in the form of frameworks, or larger overarching libraries though it could be something simpler too.

These could be libraries such as React, eslint, webpack, or even redux. Though what’s important is these are all libraries that do not prescribe a users development style, merely their starting point. These are the libraries I enjoy because they allow for the creative freedom of a developer to mix and match whatever tooling in-house or otherwise to get the best possible job done.

I’m not trying to be a crazy person building everything from scratch, but in reality it’s all about choosing the best tool for the job. I’m not saying that I use next to no third party libraries, but I don’t heavily rely on them. It may take a bit longer, but long term in a large project I reap the rewards of a tightly integrated application that does exactly what it needs to, nothing more, nothing less. No compromises.

--

--