Episode ini membahas pengelolaan Jest dalam struktur monorepo: konfigurasi multi-project, menjalankan test secara selektif per paket, serta keputusan config terpusat versus config per paket.

Monorepo menyatukan banyak paket — library, service, dan aplikasi — dalam satu repository. Ini efisien, tetapi menantang untuk tooling yang harus tahu konfigurasi mana berlaku untuk paket mana. Episode 17 membahas monorepos & multi-project testing dengan Jest: mengelola Jest lintas struktur monorepo, konfigurasi multi-project, menjalankan test secara selektif per paket, serta memutuskan config terpusat versus per paket.
Pendekatan yang tepat membuat suite monorepo cepat dan terorganisasi, sementara pendekatan yang salah menghasilkan konflik konfigurasi dan test yang saling mengganggu.
Monorepo biasanya memiliki struktur seperti ini:
packages/
core/
src/
index.js
package.json
api/
src/
server.js
package.json
jest.config.jsSetiap paket punya kebutuhan berbeda: core murni JavaScript dan berjalan di node, sedangkan api mungkin butuh jsdom atau setup tambahan. Satu konfigurasi global jarang cocok untuk semua — di sinilah multi-project config berperan.
Jest mendukung project mode dengan menulis daftar project di dalam satu file config:
module.exports = {
projects: [
{
displayName: "core",
testMatch: ["<rootDir>/packages/core/**/*.test.js"],
},
{
displayName: "api",
testEnvironment: "jsdom",
testMatch: ["<rootDir>/packages/api/**/*.test.js"],
setupFilesAfterEnv: ["<rootDir>/packages/api/setup.js"],
},
],
};displayName memberi label pada tiap project di output, sehingga kalian bisa melihat dengan jelas test mana milik paket mana. Setiap project membawa konfigurasinya sendiri — api memakai jsdom sementara core tetap node.
Saat menjalankan Jest dalam project mode, output menunjukkan label tiap project di samping hasilnya. Ini membuat debug jauh lebih mudah: kalian langsung tahu apakah kegagalan berasal dari paket core atau api, lengkap dengan konfigurasi yang berlaku.
Jest menyediakan flag untuk menjalankan hanya project tertentu:
npx jest --selectProjects corePerintah npx jest --selectProjects core menjalankan hanya project bernama core. Ini sangat berguna di CI: paket yang tidak berubah tidak perlu menguji ulang, sehingga pipeline berjalan jauh lebih cepat.
--selectProjects bisa dikombinasikan dengan pattern test biasa:
npx jest --selectProjects api -t "server"Perintah npx jest --selectProjects api -t "server" membatasi ke project api sekaligus hanya test yang namanya mengandung "server". Kombinasi ini memberi kontrol presisi untuk menjalankan subset yang sangat kecil saat men-debug.
Config terpusat di root cocok ketika semua paket berbagi kebijakan yang sama — misalnya clearMocks, threshold coverage, atau format laporan. Keuntungannya: satu tempat untuk mengubah kebijakan, dan konfigurasi tidak terduplikasi di 20 paket.
Config per paket lebih fleksibel untuk kebutuhan yang benar-benar berbeda — environment khusus, transform khusus, atau matchers domain yang berbeda. Kelemahannya, keputusan kebijakan tersebar dan bisa saling bertentangan.
Strategi yang umum: base config di root untuk kebijakan bersama, dan project config per paket hanya untuk menimpa hal yang memang berbeda. Setiap paket bisa memiliki jest.config.js sendiri yang di-extend dari root, sehingga duplikasi tetap minimal.
Untuk monorepo besar, alat seperti Turborepo atau Nx bisa mengorkestrasi perintah test per paket dengan caching dan dependency graph. Jest tetap menjadi runner di dalamnya — alat tersebut hanya memutuskan kapan dan paket mana yang dijalankan.
Episode 17 membahas testing dalam monorepo: konfigurasi multi-project dengan displayName, menjalankan test selektif dengan --selectProjects, serta keputusan config terpusat versus per paket dengan strategi extend dari base config.
Inti yang harus dibawa pulang:
displayName memberi label yang jelas pada output per project.--selectProjects menjalankan hanya project yang dibutuhkan.-t untuk subset yang sangat presisi.Di episode 18 selanjutnya kita akan membahas migrating & upgrading Jest — meng-upgrade versi Jest dengan aman, bermigrasi dari framework lain, menangani breaking changes dan refactoring test, serta menjaga stabilitas suite dalam jangka panjang.