Here’s why I’ll never go back to anything but a monorepo. My previous org decided on this for their source control/build dependency layout: 1. Monolith, home

Here’s why I’ll never go back to anything but a monorepo. My previous org decided on this for their source control/build dependency layout: 1. Monolith, home to front and back end, artisanal handcrafted openapi spec that plugged into nothing and was just for show. 2. Hand-painted service-cli library, which was supposedly going to be open source for customers but never was, and only mattered to the front end, back in the monolith. We manually kept it in sync with the backend, to everybody’s benefit (YFR). Hope you see it: backend changes left the monolith into the service-cli, back to the monolith. Face, meet wall. 3. A knapsack full of tiny libraries which all could have been wrapped up in one. They were all dependencies that plugged into the monolith and the service-cli. And they all had subdependencies. 4. Everything version-wise was synced via private npm registry. So if you wanted to make a change that went into the next version of monolith, but the code had to live in a leaf dependency way down at the bottom, you had to run a relay race marathon of red-tape PRs that you had to bribe your coworkers to pay attention to and/or approve. The entire time, several of us on the team were begging the core team to repair this and they basically told us “no we believe in the tenets of sadism, now take your allotted pain, feature-bitch.” This company employed 150+.