I’ve been developing JavaScript through all of the major existential changes we’ve had. Browser wars? I remember those. Trying to make a complex application before Firebug? Oh yeah, tell me about it. Having to roll my own AJAX request by hand? Vividly remember.

Something that I experienced in all of my large JS projects before the last few years was an eventual point of no return, a metaphorical event horizon, beyond which the amount of time it took to build the code locally as well as on the CI/CD system was just simply too long.

All projects start fine, but as they grow and evolve and change over time, the amount of build time seems to creep up until it becomes inimical to deploying and testing changes in any reasonable time frame. Further, it becomes very difficult to onboard new developers as any change they make is not isolated, and must take into account all of the other code in the app. Granted, frameworks and libraries like React do help to some extent, but there are no clean-cut boundaries on the source code with different features, it always had to be by convention.

It was during a project a few years ago that I finally put my foot down and decided that something needed to be done. Researching how other architects were doing it, I came across JavaScript monorepos. I was familiar with the concept of monorepos from my research on how Google structures their code base (they have two repos, one for YouTube and one for everything else, no joke), but had never thought to apply that same principle to JavaScript. So I dove in head first, made a lot of mistakes, iterated, and finally got to a place where I feel comfortable sharing my lessons learned.

This blog post is not an extensive study, but it is enough to get you interested in a way to solve two common problems we all have (i.e. sluggish build times and inability to effectively onboard new devs due to lack of feature separation), and give you enough of a context around how I approached the problem to determine how you should proceed.