The Mini-Monorepo

“Can you revert your last commit and use that third-party Dynamo locking library instead?” My team lead looked at me with his sharp, blue eyes. They were tucked under a strong brow and just visible over a large auburn beard. It gave him a permanent expression of seriousness. “Why’s that?” I asked earnestly. I was a little over a year into my first job, and I had just received an AWS certification. I was eager to put it to good use, starting by using Dynamo’s conditional writes in this library I was working on. “I want us to get rid of as much of our own code as we can. With three teams touching this monorepo, it’s too easy to add dependencies across projects. That’s what got us into this mess.” I was surprised by his answer. I expected him to say, “We don’t trust your code as much as we trust this third party,” which was a concern I was ready to dispute. I had my counterpoints all lined up. I was not, however, prepared to object to dependency concerns. Truth be told, I hadn’t even realized there were dependency concerns. <h1>Dependencies As Clear as Mud</h1> The problems weren’t hard to see after he pointed them out, though. We did have a mess, and it was caused primarily by poor dependency management. We had services depending on packages that should’ve been internal to other services, thereby breaking encapsulation. This meant that changes to the package could cause unintended consequences to the service that took on the dependency. Suddenly, the engineer working on that package had to be aware that there was another dependent and had to make sure to update both services to accommodate changes to the package. Sometimes this also meant that both services needed to be deployed simultaneously to prevent any breakages to the contracts between them. <a href="https://betterprogramming.pub/the-mini-monorepo-d50c4e5a3e43">Click Here</a>