Series

Python Monorepos in 2026

A five-part series on building Python monorepos with uv workspaces — package boundaries, Pydantic-to-TypeScript shared schemas, a Vite + React frontend co-living with FastAPI, and CI that scales.

5 parts · first published

Start with part 1 →
Python Monorepos in 2026
  1. 01

    Why a Python Monorepo: What uv Workspaces Actually Gives You

    Most Python monorepo pain in 2024 came from gluing pip-tools, tox, and path hacks together. uv workspaces makes the seam between packages a first-class concept — one lockfile, one resolver, one venv. That's what makes the monorepo worth doing.

    · 10 min read
  2. 02

    Designing a uv workspace: package boundaries that survive contact with reality

    The hardest part of a Python monorepo isn't the tooling — it's deciding where one package ends and another begins. Two rules — change boundaries and interface boundaries — and a worked example.

    · 8 min read
  3. 03

    The killer monorepo argument: Pydantic models, codegen'd to TypeScript, consumed by React

    A 20-line codegen pipeline turns Pydantic into JSON Schema into TypeScript. Rename a field on the backend and the frontend stops compiling. That's the whole point of a polyglot monorepo.

    · 8 min read
  4. 04

    A Vite + React SPA inside a uv monorepo: pnpm-workspace, dev proxy, shared types

    Two workspace managers minding their own business — uv for Python, pnpm for JS, with a thin Taskfile on top so you never have to remember both.

    · 8 min read
  5. 05

    Taming a polyglot monorepo: Taskfile, selective CI, and reproducible setup

    A monorepo's developer experience is mostly a Taskfile plus a CI workflow. Both should answer one question: what changed, and what depends on what changed?

    · 12 min read
Start with part 1 →