Alright, let’s talk about this ‘monot’ thing we tried out. Well, actually, I think the term folks use more often is ‘monorepo’, but the idea’s the same – stuffing multiple projects into one single big repository. We didn’t just jump into it blindly, you know. Things were getting messy.
We had, like, a dozen different little code repositories. One for the front-end app, another for the main API, a couple for smaller helper services, one for shared bits of code… you get the picture. Keeping track of changes across them was becoming a real chore. You’d update a shared piece, then you’d have to go update it in three other places, run tests everywhere, deal with version conflicts. It was just slowing us down. Simple changes took way too long because of all the hopping around and coordinating.
Getting Started – The Initial Plunge
So, we decided to give this monorepo approach a serious look. First step was just reading up a bit, seeing what tools were out there. Seemed like tools like Lerna or Yarn Workspaces were popular choices. We decided to start simple, using Yarn Workspaces because it felt less complex to begin with.
The process basically went like this:
- Created a new, empty repository. This was going to be our big one.
- Set up the basic structure. We decided on a ‘packages’ folder where each of our old repositories would live as a sub-directory.
- Configured Yarn Workspaces in the main file at the root. Pointed it to the ‘packages/’ directory.
- Then came the slow part: moving the code. We started with the shared library and maybe one or two smaller services. Copied the code over into their new homes under the ‘packages’ folder.
- Had to tweak their individual files a bit so they worked within the workspace setup.
Getting those first few pieces moved over felt like a small win. We could run commands from the root directory to install dependencies for all projects at once, which was neat.
Hitting Some Roadblocks
Of course, it wasn’t all smooth sailing. Once we started moving the bigger projects, like the main API and the front-end app, things got trickier.
Build times started creeping up. Running tests across everything took ages. Our initial CI/CD setup wasn’t smart enough; it just rebuilt and tested everything on every single tiny change, even if the change was only in one small corner of the repo. That was frustrating.
Dependency management also threw some curveballs. Sometimes different packages needed slightly different versions of the same library. Yarn Workspaces helped hoist common dependencies to the top level, which was good most of the time, but occasionally caused unexpected issues if two packages really needed incompatible versions. Untangling that took some head-scratching.
Setting up tooling like linters and formatters to work consistently across all packages also required some extra configuration effort. We wanted the same rules everywhere, applied easily.
Figuring Things Out
We had to tackle these problems one by one.
For the build times, we looked into smarter build tools and CI configurations. Found ways to make the system only build and test the projects that were actually affected by a code change, plus anything that depended on them. That helped. A lot.
For dependencies, we spent time aligning versions across projects where possible. For the few cases where it wasn’t feasible, we had to dig into the workspace tooling options to manage those specific conflicts more carefully. It meant being more disciplined about dependencies.
We standardized our linting and formatting configs at the root level and configured scripts to run them across all packages easily. Took a bit of setup, but worth it for consistency.
Where We Are Now
So, after all that effort, are we happy with the monorepo? Mostly, yeah. It’s definitely not perfect, but the original problems are largely gone.
Making changes across different parts of the system is way easier now. Refactoring shared code is simpler because you can update the code and all its usages in one go, within the same commit or branch. Code discovery is better too – everything’s in one place.
The initial setup pain was real, and maintaining the tooling needs ongoing attention. Build optimization is something we still keep an eye on. But overall, for our team and how we work, consolidating into this one big repository feels like it solved more problems than it created. It forced us to be more organized, which wasn’t a bad thing either. It just took some real work to get there.
