1~
2Pracując nad złożonymi projektami oprogramowania, wybór między monorepo a polyrepo może znacząco wpłynąć na produktywność zespołu i skalowalność kodu. W tym artykule analizujemy różnice, zalety i wady każdego podejścia, i pomagamy zrozumieć, które z nich jest odpowiednie dla Ciebie.
3~
4## Czym są Monorepo i Polyrepo?
5~
6### Monorepo
7~
8**Monorepo** (monolityczne repozytorium) to pojedyncze repozytorium zawierające kod źródłowy wielu projektów, usług lub pakietów, często ze sobą powiązanych.
9~
10```plaintext filename="Example Monorepo Structure"
11my-monorepo/
12  packages/
13    frontend/
14    backend/
15    shared/
16  package.json
17  turbo.json
18```
19~
20### Polyrepo
21~
22**Polyrepo** (wiele repozytoriów) oznacza, że każdy projekt, usługa lub pakiet ma własne, oddzielne repozytorium.
23~
24```plaintext filename="Example Polyrepo Structure"
25repos/
26  frontend/
27    package.json
28  backend/
29    package.json
30  shared/
31    package.json
32```
33~
34## Różnica wizualna
35~
36```mermaid
37flowchart TD
38    subgraph Monorepo
39        A1["frontend/"]
40        A2["backend/"]
41        A3["shared/"]
42    end
43    style Monorepo fill:#e0e7ff,stroke:#6366f1,stroke-width:2px
44```
45~
46```mermaid
47flowchart TD
48    subgraph Polyrepo
49        B1["frontend repo"]
50        B2["backend repo"]
51        B3["shared repo"]
52    end
53    style Polyrepo fill:#fee2e2,stroke:#ef4444,stroke-width:2px
54```
55~
56## Zalety i wady
57~
58### Monorepo
59~
60**Zalety:**
61- Ułatwia współdzielenie kodu (np. współdzielone biblioteki).
62- Atomowy refactoring w wielu projektach.
63- Centralne zarządzanie zależnościami i konfiguracjami.
64~
65**Wady:**
66- Może stać się ciężkie w miarę wzrostu bazy kodu.
67- Wymaga narzędzi do zarządzania częściowymi buildami/testami (np. Nx, Turborepo).
68~
69### Polyrepo
70~
71**Zalety:**
72- Każdy zespół/projekt jest niezależny.
73- Łatwiejsze zarządzanie dla małych projektów.
74- Umożliwia granularne polityki dostępu.
75~
76**Wady:**
77- Trudniejsze współdzielenie kodu bez publikowania pakietów.
78- Refactoring między repozytoriami jest bardziej złożony.
79- Możliwe duplikowanie konfiguracji.
80~
81## Praktyczny przykład: Monorepo z Turborepo
82~
83Załóżmy, że chcesz stworzyć monorepo z frontendem i backendem używając Turborepo.
84~
85### 1. Inicjalizacja monorepo
86~
87```bash
88npx create-turbo@latest
89```
90~
91### 2. Typowa struktura
92~
93```plaintext
94my-monorepo/
95  apps/
96    web/        # frontend Next.js
97    api/        # backend Node.js/Express
98  packages/
99    ui/         # shared component library
100    utils/      # shared functions
101  turbo.json
102  package.json
103```
104~
105### 3. Przykład workspace w `package.json`
106~
107```json
108{
109  "private": true,
110  "workspaces": [
111    "apps/*",
112    "packages/*"
113  ]
114}
115```
116~
117### 4. Przykład importu współdzielonej biblioteki
118~
119Załóżmy, że masz funkcję w `packages/utils/src/formatDate.ts`:
120~
121```ts
122// packages/utils/src/formatDate.ts
123export function formatDate(date: Date): string {
124  return date.toLocaleDateString('en-US');
125}
126```
127~
128W frontendzie:
129~
130```ts
131// apps/web/pages/index.tsx
132import { formatDate } from '@myorg/utils';
133~
134export default function Home() {
135  return <div>Today is {formatDate(new Date())}</div>;
136}
137```
138~
139## Kiedy wybrać Monorepo?
140~
141- Średnie i duże zespoły pracujące nad wieloma powiązanymi projektami.
142- Potrzeba współdzielenia kodu i przeprowadzania refactoringu na dużą skalę.
143- Projekty, które szybko rosną i wymagają zoptymalizowanych buildów/testów.
144~
145## Kiedy wybrać Polyrepo?
146~
147- Małe lub niezależne projekty.
148- Oddzielne zespoły pracujące nad różnymi produktami.
149- Bardzo restrykcyjne polityki dostępu.
150~
151## Podsumowanie
152~
153Nie ma idealnego rozwiązania dla wszystkich. Wybór zależy od wielkości zespołu, złożoności projektu i potrzeb współpracy. Ważne jest, aby być świadomym kompromisów i wybrać odpowiednie narzędzia do zarządzania złożonością.
154~