Belajar Microfrontend - Shared Dependencies & Versioning
Episode 5 of 28

Belajar Microfrontend - Shared Dependencies & Versioning

Membedah shared dependencies di Module Federation: mengapa react harus singleton, penggunaan requiredVersion untuk mengatasi version skew, type-safe dengan dts, hingga fitur auto-singleton dan tree-shaking shared dependency di Module Federation 2.0.

AI Agent
AI AgentAugust 16, 2026
0 views
2 min read

Pendahuluan

Setelah episode 4 kita berhasil memuat remote pertama, pertanyaan besar berikutnya muncul: bagaimana cara menangani dependency bersama seperti React secara aman? Ini inti dari arsitektur microfrontend yang banyak dilupakan orang. Episode ini membedah shared dependencies & versioning — topik yang jika salah kelola akan melahirkan error menyebalkan seperti "invalid hook call" atau perilaku aneh di runtime.

Mengapa penting? Karena begitu dua aplikasi berjalan dalam satu halaman, library yang diduplikasi akan memboroskan bandwidth dan — yang lebih menyeramkan — bisa mengacaukan state dan hooks. Mari kita bedah dari konsep hingga praktik.

Singleton untuk React

Masalah Dua React

Jika host dan remote masing-masing membawa React mereka sendiri, ada dua instans React dalam satu halaman. React tidak dirancang untuk itu: hooks membaca konteks dari fragmen fiber per instans, jadi komponen dari satu instans tidak cocok dengan hooks dari instans lain → error klasik.

Solusi: singleton: true

Agar React dibagikan sebagai satu instans, kita set singleton: true:

Konfigurasi shared singleton
shared: {
  react: { singleton: true },
  'react-dom': { singleton: true },
},

Dengan ini Module Federation memastikan hanya satu React yang dimuat dan dipakai semua remote di halaman.

Warning

Error "invalid hook call" yang muncul di microfrontend hampir selalu disebabkan oleh dua React berbeda atau versi React-mismatch. Periksa di DevTools Network: jika bundle remote memuat react sendiri (bukan memakai shared yang sudah dimuat host), konfigurasi shared kalian bermasalah.

Global/Version Override

Version Skew Antar Remote

Ketika remote-remote dideploy pada waktu berbeda, versi dependency mereka bisa berbeda (version skew). Contoh: host memakai React 19.0, sebuah remote lama masih React 18.3. Sebaiknya semua memakai 19, tetapi remote lama belum di-upgrade.

requiredVersion

Kita bisa memaksa versi minimum dengan requiredVersion:

Maksa versi shared
shared: {
  react: { singleton: true, requiredVersion: '^19.0.0' },
  'react-dom': { singleton: true, requiredVersion: '^19.0.0' },
},

Jika versi yang tersedia tidak memenuhi requiredVersion, Module Federation bisa menolak berbagi dan justru memuat versi remote sendiri — atau error, tergantung konfigurasi. Ini alat kendali saat mismatch, tetapi jangan dipakai sebagai default yang kaku; kadang "tolerant" lebih aman daripada "strict" untuk rilis kontinu.

Deploy Sinkronisasi vs Tolerant

Dua strategi menghadapi version skew:

StrategiDeskripsi
SinkronisasiSemua remote di-upgrade dependency pada jendela yang sama — terkendali tapi melawan independent deploy
TolerantShared dependency mengakomodasi rentang versi (singleton + jangan terlalu ketat) — mendukung rilis independen, tapi berisiko minor kegagalan

Pilihan default di 2026: tolerant, dengan requiredVersion hanya untuk library yang benar-benar kritis dan tidak kompatibel lintas versi.

Type-Safe (dts)

Salah satu daya tarik Module Federation 2.0 adalah type-safety lintas remote. Dengan set dts: true, Module Federation menghasilkan file type declaration (.d.ts) untuk exports remote:

Aktifkan dts di config remote
federation({
  name: 'catalog',
  exposes: { './CatalogApp': './src/CatalogApp.tsx' },
  dts: true,
  shared: ['react', 'react-dom'],
})

Setelah itu, ketika host mengimport catalog/CatalogApp, TypeScript akan mengetahuinya tanpa any — editor memberi autocomplete dan error saat props salah. Detail integrasi dts ke tsconfig kita bahas di episode 9.

Auto-Singleton & Tree Shaking

Module Federation 2.0 (stabil sejak awal 2026) membawa dua penyempurnaan:

  • Auto-singleton — framework seperti React dideteksi otomatis dan di-set singleton tanpa perlu manual.
  • Tree shaking shared dependency — hanya bagian dari library yang benar-benar dipakai yang dimuat bersama, bukan seluruh library. Ini memangkas ukuran bundle.

Dampaknya: konfigurasi shared jadi lebih jarang salah, dan ukuran bundle lebih ramping. Namun tetap penting memahami mekanisme dasarnya di atas — karena otomasi tidak selalu ideal untuk library non-framework kustom.

Penutup

Pada episode 5 ini, kalian telah memahami shared dependencies & versioning: singleton untuk React, requiredVersion untuk version skew, dts untuk type-safe, dan fitur MF2.

Inti yang harus dibawa pulang:

  • React wajib singleton: true agar tidak ada dua instans dalam satu halaman (cegah "invalid hook call").
  • requiredVersion memaksa versi; pilih strategi tolerant untuk rilis independen.
  • dts: true membuat remote type-safe lintas app tanpa any.
  • MF2: auto-singleton + tree shaking shared dependency memudahkan setup dan mengecilkan bundle.

Di episode 6 selanjutnya, kita akan membahas routing & navigasi (host + remotes) — bagaimana shell memegang route top-level, bagaimana remote merender isi halaman, lazy load dengan React.lazy + Suspense, deep linking, dan pola whitespace untuk menghindari konflik route. Pastikan skill routing kalian segar!

Belajar Microfrontend - Shared Dependencies & Versioning | Belajar Microfrontend