The Case for (and Against) One Giant Repository

We’ve been shifting back toward a monorepo at CodePen, and for us it’s been a clear win over juggling many smaller repositories. That’s not a universal conclusion — different teams face different constraints, and plenty of organizations have good reasons to go the other way. The decision often comes down to whether your pain points are technical or organizational.

Those two categories are worth separating. A technical problem is when some part of the application strains the infrastructure — say, image processing eating CPU and starving other services, which hurts latency or availability. A people problem is about team structure: 30 engineers all trying to continuously deploy the same service means queuing, and engineers waiting to deploy aren’t shipping product. Microservices can solve both kinds of problems, but the right architecture depends on which one you’re actually facing.

Why the Monorepo Works for Us

  • One source of truth. A single git pull gets you completely in sync with everyone else, with a full dev environment ready to go.
  • No scattered activity. Pull requests and issues all happen against the monorepo. Nothing gets lost in a forgotten corner of GitHub.
  • Real code sharing. Utilities and components can be used anywhere in the codebase without the janky workflow of publishing shared bits to npm for other repos to consume.
  • No zombie repos. With dozens of small repos, some inevitably fall behind on dependencies, Node versions, linting rules, and formatting. With one repo, everything ages together.

The Trade-off

The main reason we originally split things up: some code needed to live in unique places, like an individual Lambda or a standalone service on a specific server. A dedicated repo makes it easier to hook up CI/CD and other infrastructure that is specific to that deployment target. That deployment complexity is the real disadvantage of consolidating — you have to find ways to route the right pieces of the monorepo to the right places.

Not a Religious Debate

This isn’t an all-or-nothing proposition. Some teams need to limit contractor access to a subset of the codebase, or the repo size becomes genuinely unwieldy. Those aren’t issues for us right now, so the monorepo’s benefits win out. The right answer depends entirely on the size of your team, the shape of your deployments, and which kind of problem is actually hurting you.