Monorepo
One Git repository containing several apps and shared packages, with tooling that understands how they depend on each other.
What it is
A monorepo keeps multiple projects in one version-control repository: perhaps a web app, an API, a mobile app, and shared UI or configuration packages. pnpm workspaces handle local package linking, while Turborepo, Nx, and Bazel can understand the task graph and avoid rebuilding work whose inputs did not change. Google, Meta, and Microsoft all run famously large single repositories, and Bazel is Google's internal build tool made public.
Reach for it when projects change together or genuinely share code and standards. One pull request can update a library and every caller, one CI run can test the affected graph, and local packages can use normal package boundaries instead of copied files. Monorepo describes repository layout, not application architecture; the apps can still deploy independently.
The gotcha is accidental coupling. Without ownership rules, package boundaries, and filtered CI, every team can import everything and every change can trigger every task. Keep dependency directions explicit, cache only reproducible tasks, declare environment variables that affect outputs, and decide whether shared packages are versioned together or independently.
Ask AI for it
Create a pnpm workspace monorepo with apps/web, apps/api, packages/ui, and packages/config, then orchestrate it with Turborepo. Add pnpm-workspace.yaml and turbo.json tasks for build, test, lint, and dev; make build depend on ^build; cache deterministic outputs; keep dev persistent and uncached; and add filtered CI commands that run only projects affected by the base branch.