On the importance of monorepos and component libraries

It’s a great thing to be able to work on clean, tested, and very well-maintained front-end codebases, I know, but it’s also rare to find them.
We all know it, and yet if you tell someone something like that, you’ll likely get mocked that you work on a shitty project and who knows what.

Apart from getting distances from such behaviors, the reality is much more complicated than that: clients don’t pay on time, budgets are tight, budget is low to even deliver the requested features, time is running out, and many other reasons depending also on the type of company you own or work for.

Don’t get me wrong: testing is important, but no one prevents you to change the environment you work in and bending it as much as you can towards well-known best practices in the software development world.
As I always say: act, don’t complain. (but I often do both sadly 😂)

Furthermore, I strongly believe that taking part in the process of improving the development standards in a company, is one of the best things that can happen to you. Maybe even better than working for a company with high standards already and the reason is quite simple: it’ll always be easier to find the first kind and then have the necessary skills to repeat the same process makes you incredibly valuable for the job market.

What can we do then?

There are ways in which a company can architecture the code in order to indirectly improve the quality of the products, other than being faster at shipping them.
The two things we’ll briefly examine today are monorepos and component libraries.

A monorepo makes sharing code between different npm packages a child’s play. If you’re working with legacy codebases containing some (or a lot of) duplicated code, put them inside a single repository, create npm packages and use something like yarn workspaces, Lerna, or NX (and many more) so that you can maximize code reuse. Even when there is no code to share apparently, it’s probably there written in a different way but doing the same thing.

A striking example? UI Components.
And even if you’re using snackbars or menus from a library like material-ui, they always require some boilerplate code to work, and especially if the apps heavily rely on those, the implementation gets a lot verbose and repetitive. So share them and you can’t go wrong.

Monorepos are framework agnostic: you can do it in React, in Vue, or in vanilla JS with no framework at all.
They’re not monoliths: for each package, the deployment can happen at different times as well as their builds, publish, and tests. There are many guides out there on how to set up one of them with your technology of choice.

Also, I’ve only talked about front-end code, but imagine if you could write node back-ends and share stuff between front and back too while working with Typescript for example…

Regarding code tests

When you organize the code in the way I’ve just described, it’s fair to say that testing gets easier but also your tests will spread like wildfire across the various packages, and this was less obvious to me.

So, while I’ve named some tools and technical concepts for you to discover, the general advice is simple: reuse as much as possible and then start testing the extracted bits. This will allow you to get the best “low effort maximum results” effect on mitigating untested codebases.

Getting practical

I thought about preparing a repo to showcase a monorepo in React Native and how one could leverage it, but I gotta admit that a fellow countryman of mine has already done this 👏🚀