pnpm Monorepos: Opus 4.7’s Default Architecture

Across 9,281 Claude Opus 4.7 repos, 454 are classified as monorepos (5% of the corpus). That’s a striking rate — for reference, under 1% of the general GitHub corpus are monorepos.

When Opus 4.7 monorepos, it uses pnpm workspaces almost exclusively. Here’s what the canonical workspace layout looks like across the corpus.

The standard workspace names

Counting workspace package names across all Opus 4.7 pnpm monorepos:

Package Count What it holds
web 29 Next.js or Vite frontend app
ui 12 Shared component library (shadcn-ified)
shared 20 Cross-package utilities / types
db 12 Prisma/Drizzle schema + client
core 11 Business logic
api 11 Route handlers / tRPC routes
cli 8 Command-line entry point
types 8 Shared TypeScript types
config 7 Shared configs (eslint, tsconfig, tailwind)
worker 5 Background job processors
mobile 5 Expo / React Native app
dashboard 4 Admin UI
auth 4 Authentication layer
utils 4 Generic helpers
sdk 4 Public-facing SDK
eslint-config 4 Shared ESLint rules
typescript-config 5 Shared tsconfig base

The canonical shape

Put together, a typical Opus 4.7 monorepo looks like:

apps/
  web/                 # Next.js / Vite frontend
  api/                 # Express / Next API / Fastify
  worker/              # Background jobs (optional)
  mobile/              # Expo (optional)

packages/
  ui/                  # shadcn components
  db/                  # Prisma schema
  shared/              # Cross-cutting utils
  types/               # Shared types
  config/              # tsconfig/eslint base

pnpm-workspace.yaml
package.json
turbo.json              # often present

Turbo is frequently added for the build pipeline — it appears in 56 repos among the top 20 frameworks.

Why pnpm?

Not yarn, not npm workspaces. pnpm because:
- Disk efficiency: content-addressable store
- Strict dependency graph: no phantom dependencies
- Fast install: parallel downloads + hardlinks
- Good with workspaces: the pnpm-workspace.yaml format is ergonomic

And crucially: pnpm is what the official shadcn docs recommend, what the Turborepo generator uses, and what Vercel’s deploy templates default to. The ecosystem pulled Opus 4.7 in that direction.

The Python monorepo

A minority trend: 24 Opus 4.7 Python monorepos with a package named backend (using pip as the manager). The typical layout:

backend/                 # FastAPI or Flask
  app/
    api/
    models/
    services/
  tests/
  pyproject.toml
  requirements.txt

frontend/                # Next.js (usually)
  pages/ or app/
  components/

Python-TS cross-stack monorepos are surprisingly common — ~40 repos combine a FastAPI backend with a Next.js frontend in a single root.

Build & dev tooling adoption

Picking out the build tools most consistently present in Opus 4.7 monorepos:

  • Vite — 583 repos, 526 with vite.config.ts
  • Turbopack — 56 (growing)
  • esbuild — 60
  • Vitest — 394 (test runner)
  • pnpm lockfile — 231 repos with pnpm-lock.yaml (only 29 with yarn.lock)

Implications for generators

If you’re building a project generator to match the Opus 4.7 distribution:

  1. Default to pnpm workspaces, not yarn or npm workspaces
  2. Scaffold apps/web, apps/api, packages/ui, packages/db as the base layout
  3. Install Turborepo for the build orchestration
  4. Use Vitest for tests, ESLint + Prettier for lint, TypeScript throughout
  5. Include shadcn-ui components in packages/ui from day one

This matches not just the shape of the average Opus 4.7 monorepo but the vocabulary — the workspace names we identified above are the ones Claude reaches for when it decomposes a project.

Related: The shadcn/ui Dominance in Opus 4.7.