Micro Libraries

Some weeks ago I stumble upon the concept of micro apps: apps that serve only one functionality/purpose, being minimal in most of the cases. And I question myself: if we have microservices and micro apps, it’s only logical that we have micro libraries, right?

So, what do these libraries offer? You guessed it, one feature/functionality. The earliest moment I remember seeing one of these libraries, was the isX libraries drama, where people claimed that JavaScript projects were becoming bloated because of the over-dependence on predicate function libraries, such as “is-number”, for something as simple as asserting if a value is a number (is-number).

While I agree that these type of libraries contribute to bloatiness, building them can be quite satisfying, because:

• they are fast to build
• they are easy to maintain
• they integrate with ease
• you are challenged to build without external dependencies and for optimization

There’s an additional rule for micro-libraries: what you build must be shipped through a single function. For JS/TS libraries, you can achieve this by exporting only that function in the main module file.

One big advantage of using micro-libraries, is that you get what you pay for. For example, if you only need feature X from library Y, why should you also depend on feature Z, W, A, B and C that are bundled with Y? This was my motivation for building github-upsert: a micro library for uploading/updating files in a GitHub repo.

I can now use this library on my Cloudflare Workers (that are limited to 1M bundle size) without depending on all the GitHub JS SDK features, just to update a file on my GitHub repo.