Trying to Use Fewer Dependencies

First published: 13/08/2024

Recently I made a couple of contributions to the e18e initiative. I created a codemod that converts usages of common NPM packages with lots of dependencies to use native JS features. You’d be shocked at how many simple packages pull in dozens (or hundreds) of dependencies.

It got me thinking about reducing my own reliance on third-party code. I’m not in favour of removing all dependencies from every package, but it puts my blind faith into question. I put a lot of faith whenever I install a package. I trust that:

• it’s well maintained
• it does the jobs it promises to do
• it’s performant
• there’s no unnecessary code (like support for old browsers + runtimes)

I also don’t believe it’s my responsibility as a package author to be concerned about things like minification. These concerns should be the responsibility of application developers as they better understand the needs of their users. (If you’re interested in library-level concerns vs application-level concerns, then I cover this in Component Odyssey).

If I were to publish a simple library that installs a commonly-used dependency like Lodash, even for a single function, like isObject, anyone using my component library will also have to install the Lodash dependency. This results in longer install times, heavier node_modules directory, and a worse experience for the end user if the developer doesn’t correctly optimise their project.

I wanted to avoid any third-party dependencies if possible in my most recently published component, <masonry-gallery>. <masonry-gallery> is a focused component. It renders its children as a masonry layout. Considering that the component does little more than re-order its children based on the element heights, I didn’t see a need to rely on any third parties.

The logic was fairly straightforward, but instead of leaning on Lodash for an isEmpty and a debounce function, I used the You Might Not Need Lodash GitHub repo to guide me into writing the equivalent code directly in my project.

As a result, the <masonry-gallery> package has zero dependencies and is 2.4kb minified, 1.1kb minified + gzipped.

This simplifies my dev environment too and makes it easier to publish code that works across a range of different projects by default.