A monorepo is a single git repository that holds many distinct projects: multiple apps, shared libraries, infrastructure code, all in one place. The opposite is a polyrepo (one repo per project). Google, Facebook, and Microsoft famously run monorepos with hundreds of millions of lines of code. Tools like Nx, Turborepo, Bazel, and pnpm workspaces make monorepos workable for smaller teams.
A monorepo has a workspace configuration (pnpm-workspace.yaml, turbo.json, nx.json) that lists project locations and shared scripts. Build tools track dependencies between projects and only rebuild what changed. CI runs tests for affected projects, not the whole repo. Shared dependencies are hoisted to a single node_modules (in JavaScript ecosystems), reducing disk usage.
Monorepo tradeoffs: easier cross-project refactors and atomic changes, but slower CI on bad days, more complex tooling, and a steeper learning curve. The break-even point is usually 3-5 related projects.
Monorepos shine when projects share code, deploy together, or evolve in lockstep. They are the default for full-stack apps, design systems, and platform teams. For genuinely independent projects with separate deploy cycles, polyrepos are still simpler.
TerminalFeed itself is a small repo with a frontend and a worker; not quite a monorepo but follows similar conventions for shared types and tooling.