Turborepo: Kenapa CI Monorepo-mu Selalu Build Ulang Semua Package Padahal Cuma Ubah 1 File?

Bayangin Tim Budi Cuma Ganti 1 Baris Teks di Satu Package...

Bayangin perusahaan Budi punya satu monorepo berisi 8 package: web, mobile, admin-dashboard, dan 5 package shared lainnya seperti ui dan utils. Suatu hari, seorang rekan tim cuma mengganti satu baris teks tombol di dalam package ui, lalu melakukan git push.

Pipeline CI mereka pun mulai berjalan — dan seperti biasa, dengan setia mem-build ulang seluruh 8 package dari nol, satu per satu, menghabiskan waktu 12 menit penuh, walaupun 7 dari 8 package itu sama sekali tidak tersentuh oleh perubahan tadi.

Masalahnya: Sistem Build Standar Tidak Tahu Mana yang 'Benar-Benar Berubah'

Perintah build standar (seperti npm run build di setiap folder) tidak punya memori tentang build sebelumnya. Setiap kali dijalankan, dia menganggap semuanya harus dikerjakan ulang dari awal — tidak peduli apakah source code-nya benar-benar berbeda dari build terakhir yang sukses atau tidak.

Nah, Di Sinilah 'Turborepo' (Build Caching untuk Monorepo) Masuk!

Turborepo menambahkan lapisan cerdas di atas perintah build biasa, dengan konsep inti bernama content-aware hashing:

1. Sebelum menjalankan build pada sebuah package, Turborepo menghitung sebuah hash unik dari seluruh isi file sumber package itu (dan package lain yang menjadi dependensinya).
2. Turborepo mengecek: "Apakah saya pernah menjalankan build dengan kombinasi hash yang persis sama ini sebelumnya?" Kalau iya (baik dari cache lokal di komputer developer, maupun dari cache remote yang dibagikan satu tim), Turborepo langsung mengambil hasil build lama dari cache dalam hitungan detik, tanpa menjalankan proses build ulang sama sekali.
3. Hanya package yang hash-nya benar-benar berubah (karena source code-nya diubah, atau salah satu dependensinya berubah) yang benar-benar di-build ulang dari nol.

// turbo.json
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    }
  }
}

Untuk kasus tim Budi tadi: karena cuma package ui yang isinya berubah, dan web ikut ter-build ulang karena bergantung padanya, tapi mobile, admin-dashboard, dan package lain yang tidak bergantung pada ui semuanya diambil dari cache — pipeline yang tadinya 12 menit bisa turun drastis jadi hitungan detik.

Intinya: Di arsitektur monorepo, waktu CI yang membengkak biasanya bukan karena kodenya lambat, tapi karena sistem build-nya tidak tahu cara mengenali "apa yang sebenarnya berubah". Tooling seperti Turborepo (atau Nx) menyelesaikan itu dengan cache berbasis isi file, bukan berbasis waktu atau tebakan.