Vilka är monorepo jämfört med polyrepo strategier?

Question

Accepted Answer

**Monorepo** (en repository för många projekt/tjänster) och **polyrepo** (en separat repository per projekt) är två strategier för att organisera kod över flera projekt. Var och en har betydande kompromisser som påverkar samarbete, verktyg och skalning — att förstå dem informerar viktiga arkitektoniska beslut.

## Monorepo — en repo för allt

```text
Many projects/services/libraries in a SINGLE repository:
  ✓ SHARED code/libraries easy to use and refactor (one place, atomic changes)
  ✓ ATOMIC commits across projects (change an API and all its consumers together)
  ✓ Unified tooling, versioning, CI; consistent standards; easy cross-project visibility
  ✓ Simplified dependency management (one version of shared code)
  ✗ Repo can get HUGE (needs scaling tooling — sparse checkout, build caching)
  ✗ Needs sophisticated build/CI tooling (Nx, Turborepo, Bazel) to be efficient
  ✗ Broad access; CI must be smart (only build what changed)
→ Used by Google, Meta, etc. (with heavy tooling investment).
```

## Polyrepo — en repo per projekt

```text
Each project/service/library in its OWN repository:
  ✓ Clear OWNERSHIP and boundaries; independent versioning/releases/CI
  ✓ Smaller, focused repos; granular access control; independent teams
  ✗ SHARED code is harder (publish/consume packages; version coordination)
  ✗ Cross-cutting changes span MANY repos (coordinate multiple PRs — painful)
  ✗ Potential inconsistency across repos (tooling, standards drift)
→ Common default; fits independent services/teams.
```

## Välja

```text
MONOREPO → tightly-coupled projects, heavy code sharing, want atomic cross-project
  changes and unified tooling, willing to invest in scaling tooling
POLYREPO → independent projects/teams, clear boundaries, independent release cycles,
  simpler per-repo needs
→ No universal answer; depends on the org, coupling, scale, and tooling investment.
```

## Varför det spelar roll

Att förstå monorepo jämfört med polyrepo strategier är värdefull kunskap på seniorni­vå för **att fatta välgrundade arkitektoniska beslut om kodorganisation**, ett betydande val med långtgående konsekvenser, så det är användbart för senior-/arkitektoniska roller.

De två metoderna — **monorepo** (många projekt i en repository) och **polyrepo** (en separat repository per projekt) — representerar fundamentalt olika organisatoriska filosofier med verkliga kompromisser. **Monorepo** fördelar (enkel delad kod och refaktorering, **atomära tvärprojekt-commits** — ändra ett API och alla dess konsumenter tillsammans, enhetligt verktyg och standarder, förenklad beroendehantering) gör den kraftfull för tätt kopplade projekt med omfattande koddelning, men det kräver betydande investeringar i **skalningsverktyg** (Nx, Turborepo, Bazel, sparse checkout, smart CI) för att hantera den stora repositoryn effektivt. **Polyrepo** fördelar (tydligt ägarskap och gränser, oberoende versionering och publiceringsmöjligheter, mindre fokuserade repos, granulär åtkomst) passar oberoende projekt och team, men gör **delad kod svårare** (publicering/konsumtion av paket, versionssamordning) och **tvärsnittande ändringar smärtsamma** (samordning av PR:er över många repos).

Att förstå dessa kompromisser och hur man **väljer** (monorepo för tätt kopplade, koddelande projekt villiga att investera i verktyg; polyrepo för oberoende projekt och team med tydliga gränser) återspeglar den arkitektoniska bedömning som förväntas på seniorni­våer — att erkänna att det inte finns något universellt svar och att rätt val beror på koppling, skala, teamstruktur och verktygsinvesteringar.

Since kodorganisation över flera projekt är ett betydande arkitektoniskt beslut som påverkar samarbete, verktyg, skalning och teamautonomi, och eftersom förståelse för monorepo/polyrepo kompromisser informerar detta följdrika val, är förståelse för monorepo jämfört med polyrepo strategier värdefull kunskap på seniorni­vå för arkitektonisk beslutsfattning, ett ofta debatterat ämne där förståelse för kompromisserna (i stället för att dogmatiskt förespråka en) återspeglar den mogna bedömning som förväntas för seniorroller som formar hur en organisation strukturerar sin kod.