Monorepo
A single version-controlled repository containing multiple related packages or services with shared tooling.
A single version-controlled repository containing multiple related packages or services with shared tooling.
A monorepo stores multiple distinct packages or services in a single git repository with shared build tooling, dependency management, and CI configuration. Packages can depend on each other directly by path, avoiding the publish-install cycle of polyrepos. Common tooling: Turborepo (build caching and task orchestration), pnpm workspaces (shared node_modules with symlinks), Nx (graph-aware task scheduling). The tradeoff: unified dependency management and atomic cross-package commits in exchange for a larger repo surface and tooling complexity. Monorepos excel when packages share code, need coordinated releases, or are owned by one team.
How It Works
One git root → packages/ or apps/ subdirectories → workspace-aware package manager resolves cross-package imports → build tool caches outputs by content hash, skipping unchanged packages.
Example
The AutoHunt job automation system was scaffolded as a monorepo: 9 packages, 107 files, Turborepo plus pnpm workspaces, all in one day. Every interface boundary set on that first day survived three project renames and a full SaaS migration because the domain boundaries were encoded in package structure, not in file paths.