Node Modules di JavaScript: Kenapa Ukurannya Bisa Jauh Lebih Besar dari Source Code?

Meme tentang node_modules yang jauh lebih besar daripada source code aplikasi memang sudah menjadi bahan tertawaan klasik di kalangan programmer web modern. 😂

Source code aplikasi yang kita tulis sendiri mungkin hanya berukuran beberapa ratus kilobyte, tetapi setelah menjalankan npm install, ukuran folder node_modules bisa membengkak menjadi ratusan megabyte bahkan beberapa gigabyte.

Lalu, kenapa perkembangan web modern bisa sampai seperti ini? Mari kita bandingkan era sebelum node_modules dengan development JavaScript modern.

1. Era Sebelum Node Modules: Vanilla JavaScript dan jQuery

Pada masa ketika website masih banyak dibangun menggunakan Vanilla JavaScript, jQuery, HTML, dan CSS, struktur project biasanya jauh lebih sederhana.

Ukuran Project Sangat Ringan

Ukuran project sering kali hanya berada di kisaran beberapa kilobyte sampai beberapa megabyte, terutama untuk website sederhana.

Manajemen Library Masih Sederhana

Kalau membutuhkan library tambahan, developer biasanya cukup memasukkan CDN melalui tag <script>.

<script src="https://cdn.example.com/jquery.min.js"></script>

Alternatif lainnya adalah mengunduh file JavaScript seperti jquery.min.js, lalu menyimpannya langsung di folder project.

Project Mudah Dipindahkan

Karena ukurannya kecil, seluruh folder project gampang di-ZIP, dipindahkan menggunakan flashdisk, atau bahkan dikirim lewat email tanpa terlalu memikirkan kapasitas penyimpanan.

2. Era Modern Node Modules: React, Vue, Next.js, dan Framework JavaScript Modern

Cara kerja development web berubah drastis ketika ekosistem Node.js dan package manager JavaScript semakin dominan.

Framework seperti React, Vue, Next.js, Nuxt, Angular, Svelte, dan berbagai tooling modern sekarang mengandalkan dependency yang dikelola melalui package manager.

Source Code Kecil, node_modules Bisa Sangat Besar

Source code yang kita tulis sendiri mungkin hanya sekitar:

src/
± 300 KB

Tetapi setelah menjalankan:

npm install

kita bisa mendapatkan:

node_modules/
± ratusan MB hingga beberapa GB

Tentu ukurannya sangat bergantung pada framework, tooling, dan jumlah dependency yang digunakan oleh project.

Kenapa node_modules Bisa Membengkak?

Salah satu penyebab utamanya adalah dependency tree.

Ketika kita meng-install satu package, package tersebut bisa membutuhkan sejumlah dependency lain. Dependency tersebut kemudian bisa memiliki dependency tambahan lagi.

Aplikasi
└── Library A
    ├── Library B
    │   ├── Library D
    │   └── Library E
    └── Library C
        ├── Library F
        └── Library G

Akibatnya, satu perintah instalasi sederhana dapat menghasilkan ratusan bahkan ribuan package di dalam dependency tree.

npm, Yarn, pnpm, dan Bun

Ekosistem JavaScript modern memiliki beberapa package manager populer, antara lain:

• npm
• Yarn
• pnpm
• Bun

Tool tersebut membantu developer mengelola dependency, versi package, script development, build process, testing, linting, hingga berbagai proses otomatis lainnya.

Pendekatan masing-masing package manager juga berbeda. Sebagai contoh, pnpm menggunakan content-addressable storage dan linking untuk mengurangi duplikasi dependency di disk.

Kenapa Developer Rela Menggunakan node_modules yang Besar?

Jawabannya adalah Developer Experience (DX).

Ukuran dependency yang besar merupakan salah satu trade-off untuk mendapatkan berbagai kemudahan dalam development modern.

• Komponen dan fitur siap digunakan.
• Build system yang otomatis.
• Type checking dan linting.
• Hot Module Replacement atau Fast Refresh.
• Testing tools.
• Bundling dan minification.
• Tree shaking.
• Code splitting.
• Pengelolaan dependency yang terstruktur.

Jadi, node_modules sebenarnya lebih tepat dianggap sebagai peralatan dan bahan baku untuk proses development, bukan ukuran aplikasi yang nantinya dikirim secara utuh ke pengguna.

Apakah Seluruh node_modules Dikirim ke Production?

Umumnya tidak.

Pada aplikasi frontend modern, proses build akan mengambil bagian kode yang dibutuhkan lalu melakukan optimasi seperti bundling, minification, tree shaking, dan code splitting.

Hasil production bisa jauh lebih kecil dibanding folder node_modules yang digunakan saat development, meskipun ukuran akhirnya tetap bergantung pada aplikasi dan dependency yang digunakan.

Source Code
     +
node_modules
     +
Build Tools
     ↓
   Build
     ↓
Production Assets
HTML + CSS + JavaScript

Analogi node_modules yang Paling Mudah

Sebelum era node_modules, membangun aplikasi web bisa dianalogikan seperti ingin membuat kue cokelat.

Kita pergi ke warung, membeli tepung, telur, dan cokelat seperlunya, lalu membawanya pulang menggunakan kantong kresek dan langsung membuat kuenya. Simpel dan ringan.

Tapi di era node_modules, ceritanya sedikit berbeda.

Demi membuat satu kue cokelat, programmer modern seolah membawa seluruh pabrik tepung, kandang ayam petelur, mesin pengaduk, gudang bahan baku, dan peralatan produksi langsung ke dapur rumah. 😂

Memang terlihat berlebihan, tetapi semua "pabrik" tersebut membuat proses produksi berikutnya menjadi jauh lebih cepat, otomatis, dan konsisten.

Kesimpulan

Folder node_modules yang besar bukan semata-mata karena JavaScript modern boros.

Ia merupakan konsekuensi dari ekosistem development yang semakin kompleks, modular, dan kaya akan tooling.

Dulu kita membawa beberapa file JavaScript. Sekarang kita membawa satu ekosistem lengkap untuk membantu proses development.

Jadi meme "App 300 KB, node_modules 12 GB" memang berlebihan, tetapi sebagai representasi kehidupan programmer JavaScript modern... rasanya tetap cukup relatable. 😂

CMIIW. 🙃