Monorepo vs polyrepo

Un repository o tanti?

Quando un'organizzazione gestisce piu progetti e librerie, si pone una scelta strutturale: tenere tutto in un unico repository (monorepo) o distribuire il codice su molti repository separati (polyrepo). Non c'e una risposta universale, ma compromessi da valutare.

Il monorepo

Un monorepo raccoglie piu progetti in un solo repository. Facilita la condivisione di codice, i refactoring trasversali e l'allineamento delle versioni: una modifica a una libreria e ai suoi consumatori avviene in un unico commit.

• Pro: refactoring atomici, dipendenze allineate, visibilita totale.
• Contro: repository grande, serve tooling per build e CI selettive.

Il polyrepo

Il polyrepo assegna un repository a ciascun progetto. Garantisce confini netti, permessi granulari e cicli di rilascio indipendenti, al prezzo di una maggiore frammentazione.

• Pro: autonomia dei team, repository snelli, ownership chiara.
• Contro: condivisione del codice piu complessa, versioni da coordinare.

Il fattore decisivo: il tooling

La differenza pratica la fa il tooling. Un monorepo regge bene solo con strumenti che eseguono build e test sui soli progetti toccati da una modifica:

# build solo dei progetti impattati
npx turbo run build --filter=...[origin/main]

Come scegliere

Team affiatati che condividono molto codice traggono vantaggio dal monorepo; organizzazioni con prodotti indipendenti e team autonomi spesso preferiscono il polyrepo. In MUSTNODE SRL adottiamo l'uno o l'altro in base alla dimensione del team e al grado di accoppiamento tra i progetti.