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-appHar du:
company/monorepo
├── apps/frontend
├── apps/backend
├── apps/mobile
└── packages/shared-componentsTools 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.jsonHvorfor det virker for os:
- Én TypeScript kodebase - Types deles automatisk mellem frontend og worker
- Shared packages -
packages/documentsbruges af både web og worker - Parallel development -
bun run devstarter 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:
| Feature | Turborepo | Nx |
|---|---|---|
| Setup tid | 5 minutter | 15-30 minutter |
| Remote caching | Gratis (Vercel) | Betalt (Nx Cloud) |
| Graph visualisering | Devtools | Nx Graph (redesignet) |
| Package managers | Alle | Alle |
| Enterprise features | Basis | Conformance, Polygraph |
| AI integration | Ingen | Cursor/Copilot config |
| Polyglot (Java, .NET) | Kun JS/TS | Maven, Gradle, .NET |
| Rust-powered core | Nej | Delvist |
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.