Kalau kamu pernah tanya ke developer soal monorepo vs polyrepo, siap-siap dapat jawaban panjang yang isinya semua teori. Saya juga dulu begitu — baca dokumentasi, nonton talk dari engineer Google atau Meta, lalu bingung sendiri karena situasi mereka beda jauh sama kondisi proyek saya.
Jadi saya mau cerita dari pengalaman nyata. Bukan dari skala perusahaan raksasa, tapi dari proyek kecil-menengah yang kamu dan saya mungkin hadapi sehari-hari.
Dulu Saya Polyrepo Fanatik
Waktu pertama kali membuat beberapa proyek bersamaan — katakanlah ada REST API, ada frontend React, ada library util yang dipakai keduanya — saya instinctively membuat tiga repo terpisah. Kelihatannya rapi kan? Setiap repo punya tujuan jelas, pipeline CI/CD sendiri, dan tim bisa kerja sendiri-sendiri.
Masalah mulai muncul ketika library util-nya perlu update. Alurnya jadi:
- Update kode di repo
utils - Bump versi, publish ke npm (atau npm link kalau lokal)
- Buka repo
api, update dependency - Buka repo
frontend, update dependency juga - Test dua-duanya
- Baru deploy
Buat perubahan sekecil apapun. Ini makan waktu dan membuat frustrasi.
Monorepo Bukan Sekedar “Satu Folder Gede”
Saya kemudian coba monorepo, dan yang penting dipahami dulu: monorepo bukan berarti kamu taruh semua kode dalam satu folder tanpa struktur. Itu namanya “mudball” dan itu bencana.
Monorepo yang proper punya struktur seperti ini:
my-workspace/
├── apps/
│ ├── api/
│ └── frontend/
├── packages/
│ └── utils/
├── package.json # root workspace
└── pnpm-workspace.yaml
Dengan workspace (pnpm, yarn, atau npm workspaces), ketika saya update packages/utils, apps/api dan apps/frontend langsung kebagian perubahan itu tanpa perlu publish ke npm dulu. Ini game changer.
Apa yang Saya Rasakan Setelah Pakai Monorepo
Yang Enak
Refactor jadi lebih berani. Kalau saya rename function di utils, TypeScript langsung beri tahu di mana saja breakage-nya — di api, di frontend, semuanya sekaligus. Dulu? Saya harus test manual satu-satu.
Satu PR untuk perubahan lintas repo. Sebelumnya, kalau ada fitur yang ngejalanin perubahan di tiga tempat, saya harus koordinasi tiga PR di tiga repo berbeda. Sekarang satu PR, satu review, satu merge.
Konsistensi config lebih mudah. ESLint, Prettier, TypeScript config — bisa di-share dari root. Tidak ada lagi kejadian tsconfig di satu repo beda sama yang lain karena lupa sinkronisasi.
Yang Tidak Enak
Clone pertama kali itu berat. Kalau proyeknya sudah gede, git clone bisa makan waktu lama. Ini serius, terutama kalau di-onboard developer baru.
CI/CD jadi lebih kompleks. Kamu harus setup “affected builds” — supaya kalau yang berubah cuma frontend, pipeline buat api tidak ikut jalan. Tools seperti Turborepo atau Nx bisa bantu, tapi ada learning curve-nya.
Semua orang lihat semua kode. Ini bisa jadi masalah kalau ada bagian kode yang seharusnya restricted. Di polyrepo, access control lebih granular by default.
Kapan Pilih Monorepo?
Pilih monorepo kalau:
- Kamu developer solo atau tim kecil yang ngelola beberapa app yang saling berbagi logika
- Banyak shared code antara app-app yang ada
- Kamu yang deploy semuanya — tidak ada tim lain yang punya control terpisah
- Ingin refactor lintas-modul lebih sering
Kapan Tetap di Polyrepo?
Tetap polyrepo kalau:
- Setiap repo benar-benar independent — beda tech stack, beda tim, tidak ada shared code sama sekali
- Ada kebutuhan access control ketat per service
- Tim-nya besar dan tersebar, dan setiap tim butuh otonomi deploy penuh
- Tech stack-nya heterogen — satu Python, satu Go, satu JavaScript. Monorepo lebih awkward di sini.
Tool yang Membuat Monorepo Lebih Enak
Kalau kamu mau coba monorepo, jangan bare-bone. Pakai salah satu dari ini:
- Turborepo — dari Vercel, ringan, bagus buat task pipeline dan caching build
- Nx — lebih feature-rich, ada code generator, tapi lebih berat setup-nya
- pnpm workspaces — kalau mau minimalis, ini saja cukup sebagai fondasi
Saya personally sekarang pakai Turborepo + pnpm workspaces. Setup-nya sekitar setengah hari, dan setelah itu hidup jadi lebih mudah.
Kesimpulan: Tidak Ada yang Selalu Benar
Monorepo bukan peluru ajaib, polyrepo juga bukan. Ini soal context.
Kalau proyeknya punya banyak shared code, kamu atau tim kamu yang manage semuanya, dan sering refactor lintas-modul — monorepo akan memberi ROI yang bagus. Kalau proyeknya benar-benar independent dan tim-nya besar dengan otonomi masing-masing — polyrepo lebih masuk akal.
Yang paling penting: jangan terlalu overthink di awal. Mulai dengan yang paling simple, dan migrate kalau sudah ada pain point nyata. Arsitektur yang paling baik adalah yang kamu dan timmu bisa maintain dengan nyaman.
Punya project yang strukturnya lagi membuat pusing? Atau mau diskusi soal setup monorepo dari nol? Yuk ngobrol — hubungi mafadev.
Leave a Reply