Spring til indhold
TBH
Tilbage til blog
9. januar 20265 min læsetid

Monorepos og Turborepo: Hvornår det giver mening

Vi bruger monorepos til flere af vores projekter - herunder vores AI RAG-applikation. Når du har en samlet kodebase hvor frontend, backend og shared components lever sammen, er det markant nemmere at arbejde på tværs.

Men monorepos er ikke for alle. Her er vores praktiske guide til hvornår det giver mening - og hvornår du skal holde dig til separate repos.

Hvad er en monorepo?

En monorepo er ét repository der indeholder flere projekter. I stedet for:

company/frontend-repo
company/backend-repo
company/shared-components
company/mobile-app

Har du:

company/monorepo
├── apps/frontend
├── apps/backend
├── apps/mobile
└── packages/shared-components

Tools som Turborepo, Nx, og Lerna hjælper med at håndtere builds, caching, og dependencies på tværs af projekterne.

Hvornår giver monorepos mening?

1. Du har 3+ apps der deler betydelig kode

Hvis din frontend, backend, og mobile app alle bruger de samme TypeScript types, UI komponenter, og utility funktioner - så giver en monorepo mening.

Nøgleord: betydelig kode. Hvis du deler 2-3 små utility funktioner, er det ikke nok.

2. Du har separate teams der arbejder på relaterede projekter

Monorepos gør det nemmere at:

  • Lave atomic commits på tværs af projekter
  • Opdatere shared dependencies én gang
  • Se hele systemet i én IDE

3. Du har brug for konsistent tooling

Same linting rules, same test setup, same CI/CD pipeline for alle projekter.

Konkret eksempel: Vores AI-platform

Vi bruger Turborepo til en enterprise dokument-søgning platform vi er ved at bygge. Strukturen ser sådan ud:

project/
├── apps/
│   ├── web/           # Next.js frontend
│   └── worker/        # BullMQ background jobs
├── packages/
│   ├── db/            # Database client og schema
│   ├── documents/     # Chunking og text processing
│   └── shared/        # Types og validering
└── turbo.json

Hvorfor det virker for os:

  • Én TypeScript kodebase - Types deles automatisk mellem frontend og worker
  • Shared packages - packages/documents bruges af både web og worker
  • Parallel development - bun run dev starter alt på én gang
  • Cached builds - Turborepo builder kun det der ændres

Hvornår er det overkill?

1. Du har ét produkt

Hvis du bygger én webapp med én backend - hvorfor splitte det op for så at samle det igen?

En simpel Next.js app med API routes er fint. Du behøver ikke "apps/web" og "packages/ui" og "packages/config".

2. Dit team er under 5 udviklere

Monorepos løser koordinationsproblemer mellem teams. Hvis I sidder ved siden af hinanden, kan I bare tale sammen.

3. Du starter et nyt projekt

Monorepos tilføjer kompleksitet fra dag ét:

  • Mere kompliceret CI/CD setup
  • Længere build times (uden caching)
  • Mere konfiguration at vedligeholde

Start simpelt. Migrer til monorepo når du har problemet, ikke før.

Alternativerne

npm workspaces

Hvis du bare vil dele kode mellem 2 projekter, er npm workspaces ofte nok:

{
  "workspaces": ["packages/*", "apps/*"]
}

Ingen Turborepo, ingen Nx - bare native npm.

Git submodules

Fungerer teknisk for read-only dependencies - men sjældent en god developer experience. Versionering og CI-integration bliver hurtigt besværligt.

Package registry

Publicér dine shared packages til npm (eller en privat registry). Mere overhead, men klarere grænser.

Hvorfor vi bruger Turborepo

Turborepo har udviklet sig massivt. Med v2.7+ er det blevet et seriøst værktøj:

Devtools og visualisering

Turborepo's nye Devtools lader dig visuelt udforske din Package Graph og Task Graph. De hot-reloader når du ændrer kode - fantastisk til debugging af cache-problemer.

Intelligent caching

Remote caching via Vercel betyder at builds deles på tværs af dit team. Én udvikler builder, alle andre får cache hit. På større projekter sparer det timer hver dag.

Composable configuration

Med extends kan packages arve konfiguration fra hinanden. Slut med at copy-paste tsconfig og eslint regler.

Yarn/npm/pnpm/Bun support

Virker med alle package managers. Vi bruger Bun - det fungerer perfekt.

Turborepo vs Nx

Begge har udviklet sig meget i 2025. Her er en ærlig sammenligning:

FeatureTurborepoNx
Setup tid5 minutter15-30 minutter
Remote cachingGratis (Vercel)Betalt (Nx Cloud)
Graph visualiseringDevtoolsNx Graph (redesignet)
Package managersAlleAlle
Enterprise featuresBasisConformance, Polygraph
AI integrationIngenCursor/Copilot config
Polyglot (Java, .NET)Kun JS/TSMaven, Gradle, .NET
Rust-powered coreNejDelvist

Vores valg: Turborepo

Vi bruger Turborepo fordi:

  • Simpelhed - Mindre konfiguration, hurtigere start
  • Gratis caching - Vercel integration uden ekstra omkostninger
  • Perfekt til JS/TS - Vores primære stack

Hvornår Nx er bedre

  • Enterprise monorepos med 50+ projekter
  • Polyglot workspaces (Java, .NET, Gradle)
  • Avanceret CI med self-healing og conformance
  • AI-assisted development med indbygget agent-konfiguration

De skjulte omkostninger

1. CI/CD kompleksitet

Du skal nu håndtere:

  • Hvilke projects skal bygges ved hvilke ændringer?
  • Caching af builds
  • Parallelisering af tests

2. IDE performance

Store monorepos kan gøre din IDE langsom. TypeScript language server skal indeksere meget mere kode.

3. Onboarding

Nye udviklere skal forstå hele monorepo-strukturen før de kan lave deres første PR.

Konklusion

Monorepos er et kraftfuldt værktøj - for dem der har brug for det. De fleste har ikke.

Spørg dig selv:

  • Deler jeg virkelig så meget kode mellem projekter?
  • Har jeg koordinationsproblemer mellem teams?
  • Er min nuværende struktur faktisk et problem?

Hvis svaret er nej, så behold dine separate repos. Det er ikke gammeldags - det er pragmatisk.

Se, hvad vi har bygget

Nordvec, nævn.dk, Matematik i Måneby i browseren, Semantika og open source.

Se projekterne